在這個問題上有幾個類似的問題，我仍然沒有找到足夠的理由來決定走哪條路。有或沒有存儲庫的NHibernate
真正的問題是，abstract the NHibernate using a Repository pattern或not是否合理？
看起來抽象它的唯一原因是讓你自己選擇用不同的ORM替換NHibernate，如果需要的話。但是創建存儲庫和抽象查詢看起來像增加了另一層，並且手動完成了大部分管道工作。
一種選擇是將IQueryable<T>用於業務層並使用LINQ，但從我的經驗來看，LINQ支持仍然沒有在NHibernate中完全實現（查詢並不總是按預期工作，而且我討厭花時間調試一個框架）。
儘管在業務層中引用NHibernate會傷害我的眼睛，但它本身應該是數據訪問的抽象，對吧？
您對此有什麼意見？
好的quiestions。幾天前我也在想他們。實際上，試用NHibernate 3.0 alpha（或者當前的中繼），它的新的LINQ提供程序比以前的要多得多。 （到目前爲止，我只發現了一種方法不起作用，但如果遇到默認情況下不支持的東西，就可以掛鉤自己的機制。） 我沒有問題（還沒有？）使用當前樹幹。您可以在http://www.hornget.net/packages/網站上找到「夜間」版本，以及針對它的FluentNHibernate版本。如果您知道如何使用它，Fluent會真正提高您的工作效率。 SO社區really helped me with that也是如此。
如果您的業務層對NHibernate有直接依賴關係，或者您正在編寫的小型應用程序在沒有這種抽象的情況下仍然可以維護，那麼您最好不要使用存儲庫模式。但是，如果你做得對，它可以爲你節省大量的冗餘編碼。
抽象它的原因不僅有用，因爲之後您可以用另一個ORM替換NHibernate，但由於存在一個名爲Separation of Concerns的概念，所以這是一個很好的做法。您的業務邏輯層不應該關心或瞭解如何訪問它所處理的數據。這使得維護應用程序或其不同層次變得更容易，這也使得團隊協作更容易：如果X創建數據訪問層，並且Y寫入業務邏輯，則他們不必詳細瞭解彼此的工作。
揭示IQueryable<T>是一個非常好的主意，這正是許多存儲庫實現正在做的事情。 （我也是，儘管我更喜歡將它寫入靜態類。） 當然，如果需要，您必須公開一些插入或更新實體的方法，或者用於開始和提交事務的方法。 （BeginTransaction應該只是返回一個IDisposable以避免泄露NHibernate接口，這樣可以。）
我可以給你一些指導：查看SharpArchitecture或FubuMVC Contrib的實現，以獲得關於如何做的一些想法它是正確的，這是how I solved it。
我會說一個大的YES！有一個Repository模式，保持抽象！
我個人更喜歡將NHibernate抽象成一個存儲庫模式。原因是我可能還有其他存儲庫實現緩存，模擬單元測試等。我也使用IQueryable與我的存儲庫，雖然我讓IRepository擴展IQueryable，而不是暴露在IQueryable類型的IRepository上的屬性。
另一個存儲點。有些人建議不要使其具有通用性，並在方法級別具有類型標識（即repository.Load）。然而，這是假定將有一個知道如何處理所有類型的存儲庫。我不是一個龐然大物的這個概念的忠實粉絲。如果你正在處理多個數據庫呢？還是多持久機制？或者某些數據類型保持相當靜態並且可以被緩存，但其他數據則不能。這就是爲什麼我喜歡每種類型的單獨存儲庫實例。
如何用linq添加一個新項目到數據庫？ – Paco 2010-05-01 15:15:11
@Paco：向數據庫添加一個新項目很容易抽象，我不是在談論這個。查詢是實際的問題，因爲沒有簡單的方法來通過存儲庫啓用複雜查詢而沒有足夠的編碼。 – Groo 2010-05-01 17:02:17