ORM之殤,我們需要什麼樣的ORM架構?

標籤：users   整理   active   strong   ring   sts   調試   efi   model   

最近在研究ORM,究竟什麼樣的架構才是我們想要的

開發架構的意義在於

• 開發更標準,更統一,不會因為不同人寫的代碼不一樣
• 開發效率更高,無需重新造輪子,重複無用的代碼,同時簡化開發流程
• 運行效率得到控制,程式穩定性得到提高

把網上關注比較多的架構搜了搜,作了個列表

1. Nhibernate
   來源於Java的Hibernate
   參考:http://www.cnblogs.com/ylwn817/articles/1963528.html
2. Entity Framework
   微軟本家架構,都比較熟悉
3. iBATIS.NET
   apache開源項目
   參考:http://developer.51cto.com/art/200907/137796.htm
4. Nbear
   部落格園Teddy開發的項目
   參考:http://www.cnblogs.com/teddyma/archive/2006/11/07/553562.html
5. Castle ActiveRecord
   ActiveRecord是Hibernate的一個延伸
   參考:http://terrylee.cnblogs.com/archive/2006/04/03/365762.html

加再上其他人寫的一些架構,包括自已寫的,大差不差

整理了一些常用的特性,對這些架構作一個評分

1. 可程式化性(文法支援) 我們希望不再用字串的形式拼接SQL,並且能通過編譯驗證
2. 容錯性 可看作是上面擴充,不希望一個地方改了,其它地方沒改,沒任何提示,造成錯誤
3. 開發效率 包括架構的配置,開發過程
4. 關聯查詢支援度 關聯查詢是不可避免的
5. 額外配置 是否需要額外配置和第三方工具支援,影響開發效率
6. 緩衝支援 能大大增強程式效率

跟資料庫打交道,最重要的功能當屬查詢了,查詢做得好不好直接影響易用度,Lambda和Linq方式為首選

下面是對這些架構的分析,沒有仔細研究,可能不對,只代表個人意見,僅供參考

Nhibernate

新版Nhibernate增加了Lambda和Linq查詢支援

Join好像也能實現了

1234	var list1 = session.CreateCriteria<Product>()    .Add(Restrictions.Eq("Discontinued", false))    .Add(Restrictions.Eq("Category.Id", 2))    .List<Product>();

對緩衝支援也有,有多種實現方式
http://www.cnblogs.com/lyj/archive/2008/11/28/1343418.html

只是一如既往需要配置XML映射

Entity Framework

在上述特性中,除了沒有緩衝,EF都比較完美,關且在最新版7中,強制了CodeFirst模式,是其它架構沒有的(這樣更符合業務開發模式)

有的說EF太過龐大,用不好效率會有些問題,確實,特別是關聯,寫不好就弄出沒效率的SQL語句,這也正是他可程式化性太強的緣故,如果不是這麼強,就不會這麼寫,會想想把結構好好設計設計

由於太過於對象的概念,預設不支援批次更新/刪除

iBATIS.NET

除了有基本的對象映射優點只剩靈活來描述了,所有操作都需要配置XML檔案來表示

123456

﹤select id="GetAllAccountsAsHashMapViaResultMap"                resultMap="account-hashtable-result"﹥     select *     from Accounts     order by Account_ID ﹤/select﹥

好像還支援緩衝

1234567

﹤select id="GetCachedAccountsViaResultMap"            resultMap="account-result"            cacheModel="account-cache" ﹥     select *     from Accounts     order by Account_ID ﹤/select﹥

這已經不屬於物件導向,就是一個查詢映射

Nbear

Nbear可以通過對象的方式自動對應對象關聯,但不能直接關聯查詢
條件查詢,參數化,不太智能,好像好長時間沒更新了,不知現在是怎麼查

1	LocalUser[] users = gateway.Select<LocalUser>(_Entity.LocalUser.Id > 5 | _Entity.LocalUser.LoginId == "teddy", _Entity.LocalUser.Id.Desc & _Entity.LocalUser.LoginId.Asc);

　　

可以使用配置的方式支援緩衝,好像只能單個表

12345

<cacheConfig enable="true">    <cachingTables>      <add key="Northwind.Orders" value="5" />    </cachingTables> </cacheConfig>

除了表映射外,還支援視圖,預存程序映射,(這個其實已經脫離物件導向的概念了,設計好的業務對象,對這基本沒需求)
對象定義是介面類型,不明白

1234567891011

public interface IdentableEntity : IEntity        {            [PrimaryKey]            int Id { get; set; }            string Name { get; set; }        }

　　

Castle ActiveRecord

ActiveRecord延伸於hibernate,少不了一堆資料庫配置

也支援關聯對象,通過屬性定義

1234567891011

[HasMany(typeof(Post), Table="posts", ColumnKey="post_blogid")]   public IList Posts   {       get { return _posts; }       set { _posts = value; }   }

查詢方式為方法傳參,比較原始,不知最新的沒有引入Linq和Lambda
http://terrylee.cnblogs.com/archive/2006/04/12/372823.html

1	SimpleQuery query = new SimpleQuery(

1	typeof(Post),typeof(int),

1	@"select post.Id from Post post where post.Created between ? and ?",

1

start,end

1

);

綜合起來

	可程式化性(文法支援)	容錯性	開發效率	關聯查詢支援度	額外配置	緩衝支援
Nhibernate	Linq&Lambda文法	高	中	中	映射需要配置XML	支援
Entity Framework	Linq&Lambda文法	高	高	高		不支援
iBATIS.NET	無	低	低	高	XML配置查詢	支援
Nbear	運算子多載	高	中	中	需要工具產生類	支援
Castle ActiveRecord	無	低	中	中		支援

查詢

在設計ORM架構時,來表示查詢一般分幾種情況

• 實現linq&Lambda文法糖,藉助.NET架構實現運算式解析
• 自已寫運算式,實作類別似的效果(代價是要藉助工具產生一堆代理類,好多個人開發的架構都有這種弊病)
• 通過方法表示運算 如.BigThan("Number",">10") 這樣太複雜,可程式化性差,容錯性低
• 直接SQL 這種會造成可程式化性和容錯性低

可以看出最好的方式當屬Linq和Lambda了

 

更新

理想情況下,對象的哪個屬性修改了,就更新到哪個資料庫裡,會有以下幾種設計

1. 在屬性SET方法上做文章,以在值修改了知道是哪個屬性被更改了,更新時按此進行判斷
   代價:需要大批量修改SET方法或用模版產生(EF7好像已經解決這個問題了)
2. 參過參數的形式賦值,缺點是不太智能,可程式化性容錯性不高
3. 採用AOP訊息代理攔截屬性變動,這種效率太低,並且沒法調試

效能,緩衝

雖然現在很少看到WEB伺服器CPU佔用很高,但運行效率還是需要考慮,運行邏輯判斷時間直接影響請求回應時間,在ORM架構

這個時間多消耗在類型與資料對應,要減少回應時間,需要對映射行為進行最佳化,減少不必要的計算

開發高效的應用程式少不了緩衝的支援,資料不可能總是從資料庫讀取,也不總是非要進行關才才能獲得資料

緩衝建立,到期處理,和尋找效率也需要進行考慮,像Nhibernate和Nbear必須先進行配置才能緩衝,簡值不能忍

CodeFirst Or DbFirst

上面也提到,EF7強制了CodeFirst模式,開發觀念要發生改變了,先業務後資料,資料是基於業務實現得來的,理想情況下

有什麼樣的業務結構,就應該會有什麼樣的資料表結構,不應去管資料庫是什麼樣的,由架構來處理就行了,比如自動對應,自動建立維護資料庫

那種寫完對象結構還得再配個XML資料表對應檔的形為,得拖出去槍斃10分鐘

開發便捷性

好多架構需要用工具產生一堆代理類,增加屬性/欄位了,再產生一遍,這樣便捷性很低,就像一輛賽車開跑前先得預熱10分鐘,很讓人著急

泛類型問題:對資料進行操作時,有的必須帶上泛類型,這樣在開發時感覺帶上了一個尾巴,很冗餘,不方便

多種資料庫/多庫支援

多庫支援不可避免,這意味著架構能按業務進行配置使用哪個庫

在架構設計時基本會考慮多種資料庫支援,如果是多種資料庫多庫... 

 

以上僅為個人觀點,不對的地方請指證

ORM之殤,我們需要什麼樣的ORM架構?