帶或不帶儲存庫的 NHibernate
關於這個問題有幾個類似的問題，我仍然沒有找到足夠的理由來決定走哪條路。
真正的問題是，使用儲存庫模式抽象 NHibernate是否合理？
似乎抽象它背後的唯一原因是讓自己可以選擇在需要時用不同的 ORM 替換 NHibernate。但是創建儲存庫和抽象查詢似乎又增加了一層，而且大部分工作都是手工完成的。
一種選擇是使用暴露
IQueryable<T>到業務層並使用 LINQ，但根據我的經驗，在 NHibernate 中仍然沒有完全實現 LINQ 支持（查詢並不總是按預期工作，我討厭花時間調試框架）。雖然在我的業務層中引用 NHibernate 會傷到我的眼睛，但它本身應該是對數據訪問的抽象，對吧？
您對此有何看法？
好問題。前幾天我也在想他們。
實際上，試試 NHibernate 3.0 alpha（或目前的主幹），它的新 LINQ 提供程序比以前的提供程序要大得多。（到目前為止，我只發現了一種不起作用的方法，但是如果您遇到預設情況下不支持的東西，可以使用您自己的機制。）使用目前的主干我沒有問題（還沒有？） . 您可以在http://www.hornget.net/packages/站點上找到“夜間”建構，以及針對它的 FluentNHibernate 建構。如果您知道如何使用 Fluent，它確實會提高您的工作效率。SO 社區也確實幫助了我。
如果您對直接依賴於 NHibernate 的業務層感到滿意，或者您正在編寫一個較小的應用程序，該應用程序在沒有這種抽象的情況下仍可維護，那麼您最好不要使用儲存庫模式。但是，如果你做得對，它可以為你節省大量的冗餘編碼。
抽象它的原因不僅是因為您可以稍後用另一個 ORM 替換 NHibernate，而且由於一個名為Separation of Concerns的概念，這是一個很好的實踐。您的業務邏輯層不應該關心或知道如何訪問它所使用的數據。這使得維護應用程序或其不同層更容易，這也使團隊合作更容易：如果 X 創建數據訪問層，Y 編寫業務邏輯，他們不必詳細了解彼此的工作。
公開 an
IQueryable<T>是一個非常好的主意，這正是許多儲存庫實現現在正在做的事情。（我也是，雖然我更喜歡在靜態類中編寫它。）當然，如果您願意，您必須公開一些插入或更新實體的方法，或者用於開始和送出事務的方法。（BeginTransaction 應該只返回一個IDisposable以避免洩漏 NHibernate 介面，這樣就可以了。）我可以給你一些指導：查看 SharpArchitecture 或 FubuMVC Contrib 的實現，以獲得一些關於如何正確操作的想法，這就是我解決它的方法。