NHibernate是.NET平臺上最著名的ORM框架，雖說出身于Java平臺上的Hibernate，但是從外部看來這幾乎就是一個.NET平臺上的原生產(chǎn)品：有自己的社區(qū)，有自己的用戶，有自己的商業(yè)支持，有利用C#特性的獨(dú)立擴(kuò)展。它不像Lucene.NET那樣，一眼就能看出濃重的Java氣息，Java的命名方式等等。我用NHibernate時間不長，而NHibernate的復(fù)雜程度也決定了我無法像了解LINQ to SQL那樣容易。不過在使用了一段時間過后，還是對它有一定體會。有欣喜，有誤解，也有抱怨。

　　這幾篇文章里我不打算多談NHiberante的優(yōu)點(diǎn)，因?yàn)樗膬?yōu)勢實(shí)在過于明顯。如果不考慮Telerik ORM這樣的商業(yè)框架（因?yàn)槲覜]用過，完全不了解），.NET平臺上開源和免費(fèi)的ORM工具幾乎沒有NHibernate的對手：LINQ to SQL使用的確容易，上手非常快，某些功能也非常細(xì)致（稍后會談到），但對于ORM工具的靈魂“Mapping能力”實(shí)在是不敢恭維。前一段時間我也簡單了解了一下微軟新出的Entity Framework，雖然也秉承了微軟一貫的易用性（如強(qiáng)大的LINQ支持），在Mapping能力上也有切實(shí)的提高，但是在功能和一些細(xì)節(jié)控制上還遠(yuǎn)不如NHibernate。畢竟NHibernate是經(jīng)歷了多年發(fā)展，對于各種情況幾乎都有應(yīng)對措施。如延遲與否，是使用select還是join獲取數(shù)據(jù)，是否在集合加載時附加條件。此外，NHibernate的Interceptor能力所帶來的擴(kuò)展性也是讓我比較滿意的，不過這點(diǎn)有機(jī)會再詳細(xì)談一下。

　　總之，目前NHibernate是我最滿意的ORM框架。

　　那么現(xiàn)在進(jìn)入正文內(nèi)容。首先我想談一下自己對NHibernate實(shí)現(xiàn)方式上的一個誤解，這個誤解讓我對NHibernate一直有著錯誤的抱怨，我還在幾篇文章里不斷重復(fù)對NHibernate的錯誤職責(zé)，目前已經(jīng)糾正，希望不會造成太大問題。

　　這個誤解，是我一直認(rèn)為NHibernate使用了一種簡單的延遲加載方式。例如有這樣一個對象：

public class Article{    public virtual int ArticleID { get; set; }    public virtual string TagNames { get; set; }}

　　在延遲加載的時候，我一直以為NHibernate只是通過Emit生成一個Article的子類，然后把屬性覆蓋成簡單讀寫，例如：

public class Article$LazyProxy : Article{    private string m_tagNames;    public override string TagNames    {        get        {            return this.m_tagNames;        }        set        {            this.m_tagNames = value;        }    }}

　　這么做的問題自然是讓TagNames屬性原本的邏輯丟失了。如果對于失血的DTO模型，這自然沒有關(guān)系，因?yàn)檫@些屬性本身內(nèi)部沒有邏輯。但是，我習(xí)慣使用領(lǐng)域驅(qū)動設(shè)計（DDD）的方式來為產(chǎn)品建模，因此在這些屬性中很可能擁有一些業(yè)務(wù)邏輯。例如改變對象的其他一些狀態(tài)，同步至其他字段，或是觸發(fā)事件等等。因此，丟失屬性邏輯對我的影響是致命的，這意味著我必須“照顧”NHibernate的特性進(jìn)行編程，而在進(jìn)行建模時就開始考慮持久化邏輯是DDD實(shí)踐中的一大問題——雖然軟件開發(fā)不是理想化的，權(quán)衡是正常的，但如果NHiberante只能應(yīng)付失血的DTO模型，那么它就對不起它的業(yè)界盛名了。

　　可惜的是，NHibernate沒有在這里翻船——所以可能更應(yīng)該說“值得慶幸”——它使用了一種維持原有業(yè)務(wù)邏輯的延遲代理寫法：

public class ArticleLazyProxy : Article{    public override string TagNames    {        get        {            var tagNames = ... // 加載數(shù)據(jù)            base.TagNames = tagNames;            return base.TagNames;        }        set        {            base.TagNames = value;        }    }}

　　當(dāng)然，這是我從“測試效果”中反推出來的情況，NHiberante的實(shí)際做法應(yīng)該不會那么簡單。如果您關(guān)注我的文章，會發(fā)現(xiàn)這就是我之前提出的最為理想的延遲代理實(shí)現(xiàn)方式，也是我在Eazy類庫中使用的做法。我在實(shí)現(xiàn)了Eazy的基本功能之后，還因?yàn)樗鼭M足了我的要求而微微沾沾自喜了一把，誰知這一切早已被NHibernate拿下。我昨天晚上試驗(yàn)出這個結(jié)果之后也震驚了一把，不是因?yàn)镹Hibernate的強(qiáng)大（因?yàn)樗静辉摲复说图夊e誤），而是因?yàn)槲也焕斫庾约褐盀槭裁磿p易地臆斷NHibernate的做法？想象我還在多篇文章中抱怨過這點(diǎn)，昨天試驗(yàn)過后，我立即把自己能想到的無稽之談都修改了。慚愧啊。

NET技術(shù)：我對NHibernate的感受（1）：對延遲加載方式的誤解，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。