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

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

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

　　那么現在進入正文內容。首先我想談一下自己對NHibernate實現方式上的一個誤解，這個誤解讓我對NHibernate一直有著錯誤的抱怨，我還在幾篇文章里不斷重復對NHibernate的錯誤職責，目前已經糾正，希望不會造成太大問題。

　　這個誤解，是我一直認為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模型，這自然沒有關系，因為這些屬性本身內部沒有邏輯。但是，我習慣使用領域驅動設計（DDD）的方式來為產品建模，因此在這些屬性中很可能擁有一些業務邏輯。例如改變對象的其他一些狀態，同步至其他字段，或是觸發事件等等。因此，丟失屬性邏輯對我的影響是致命的，這意味著我必須“照顧”NHibernate的特性進行編程，而在進行建模時就開始考慮持久化邏輯是DDD實踐中的一大問題——雖然軟件開發不是理想化的，權衡是正常的，但如果NHiberante只能應付失血的DTO模型，那么它就對不起它的業界盛名了。

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

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

　　當然，這是我從“測試效果”中反推出來的情況，NHiberante的實際做法應該不會那么簡單。如果您關注我的文章，會發現這就是我之前提出的最為理想的延遲代理實現方式，也是我在Eazy類庫中使用的做法。我在實現了Eazy的基本功能之后，還因為它滿足了我的要求而微微沾沾自喜了一把，誰知這一切早已被NHibernate拿下。我昨天晚上試驗出這個結果之后也震驚了一把，不是因為NHibernate的強大（因為它本不該犯此低級錯誤），而是因為我不理解自己之前為什么會輕易地臆斷NHibernate的做法？想象我還在多篇文章中抱怨過這點，昨天試驗過后，我立即把自己能想到的無稽之談都修改了。慚愧啊。