.net - NHibernate 和存储库模式

Question

使用 Nhibernate + Repository 模式的推荐方法是什么？

周围有很多不同的文章和观点，我不知道该走哪条路。 Take this lengthy article ， 例如。它给出了一个查询对象的例子，但是每个具体的存储库都接受一个 ISession在它的构造函数中。在我的 BL(业务层)中，我应该关心哪些 NH session ？

创建一堆存储库，每个存储库都有一堆特定的方法？
显然，这是太多的工作，因为现在“允许”BL 了解 NHibernate (Repository is the new Singleton)？

创建单个通用存储库，但公开 IQueriable<T>并在 BL 中使用 LINQ
时不时会有一个查询，LINQ-to-NHibernate 将无法处理(或者我需要在一百个查询中手动调整一次 SQL)。使用自定义 repo 方法很容易，但使用依赖 LINQ 的代码几乎是不可能的。仅仅因为 LINQ 在某些情况下被破坏而使用两者都是无稽之谈。

查询对象？ QueryOver也是 NH 特定的，这意味着 BL 再次意识到 DAL 的实现。

另一种方法？

显然，我需要能够管理事务某处 ，也许使用工作单元模式(尽管周围也有许多不同的实现)。

Answer 1

在软件架构的世界中存在许多相互矛盾的观点，其中许多观点都非常有根据。

1) 是的，为每个聚合根定义一个存储库可能有点矫枉过正，但您可能会发现为该根检索数据的方式可能是特定于它的，并且您希望能够在自定义存储库中控制它。 Ayende 的文章非常有说服力，并且直击典型开发人员对“过度架构”解决方案的渴望——通常会损害功能。

2) 将 LINQ 与 NHibernate 一起使用是一种选择，但我要强调的是，如果您这样做，您必须让自己能够回退到使用标准查询或 HQL。在那个阶段，您可能会发现自己放入了很多异常，您会想知道抽象的初始点是什么。

3) QueryOver是围绕标准查询的类型安全包装器，仅此一项就使它们对我更具吸引力。我经常发现自己回退到他们提供的绝对控制标准 - 回退通常是我必须使用“魔术字符串”。这实质上将使 NHibernate 成为您的数据访问抽象。事实上，与大多数“存储库”相比，这将是一个更好的抽象，因为它们中的大多数只提供 CRUD 方法……存储库应该能够处理查询规范(确切地说 QueryOver 是如何工作的)。

就交易而言 - 这取决于您的框架。实际上，我认为在应用程序中使用工作单元模式并隐藏实现是不现实或有益的(你可以抽象它——但有什么意义？——你真的要改变你的 ORM 吗？)

如果您使用的是 ASP.NET，那么只需(至少)在请求开始时启动事务，回滚异常并在最后提交。

如果您使用的是 WinForms，那么您可能需要将每个 UI 任务的生命周期视为您的工作单元。