.net - 带或不带存储库的 NHibernate

Question

关于这个问题有几个类似的问题，我仍然没有找到足够的理由来决定走哪条路。

真正的问题是，abstract the NHibernate using a Repository pattern 是否合理？ , 或 not ?

似乎抽象它背后的唯一原因是让自己在需要时可以选择用不同的 ORM 替换 NHibernate。但是创建存储库和抽象查询似乎又增加了一层，而且大部分工作都是手工完成的。

一种选择是使用暴露 IQueryable<T>到业务层并使用 LINQ，但根据我的经验，在 NHibernate 中仍然没有完全实现 LINQ 支持(查询并不总是按预期工作，我讨厌花时间调试框架)。

虽然在我的业务层中引用 NHibernate 会伤到我的眼睛，但它本身应该是对数据访问的抽象，对吧？

您对此有何看法？

Answer 1

好问题。前几天我也在想他们。

实际上，试试 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 接口(interface)，这很好。)

我可以给你一些指导:查看 SharpArchitecture 或 FubuMVC Contrib 的实现，以获得一些关于如何正确操作的想法，这是 how I solved it .