NHibernate有或没有Repository

Question

关于这个问题有几个类似的问题,我还没有找到足够的理由来决定走哪条路.

真正的问题是,是否合理使用存储库模式抽象NHibernate的,或者不是？

似乎抽象它背后的唯一原因是如果需要的话,让自己选择用不同的ORM替换NHibernate.但是创建存储库和抽象查询看起来像添加另一层,并手工完成大部分管道工作.

一种选择是使用IQueryable<T>商业层公开和使用LINQ,但根据我的经验,LINQ支持仍然没有在NHibernate中完全实现(查询根本不能按预期工作,我讨厌花时间调试框架).

尽管在我的业务层中引用NHibernate会伤害我的眼睛,但它本身应该是数据访问的抽象,对吧？

你对此有何看法？

Answer 1

好静悄悄.几天前我也在考虑他们.

实际上,尝试NHibernate 3.0 alpha(或当前的trunk),它的新LINQ提供程序比以前的更大.(到目前为止,我只发现了一种不起作用的方法,但是如果遇到默认情况下不支持的东西,可以挂钩你自己的机制.)我没有问题(但是？)使用当前的主干.您可以在http://www.hornget.net/packages/网站上找到"夜间"构建,以及针对它的FluentNHibernate构建.如果您知道如何使用它,Fluent确实可以提高您的工作效率.SO社区也真的帮助了我.

如果您的业务层可以直接依赖于NHibernate,或者您正在编写一个较小的应用程序,在没有这种抽象的情况下仍然可以维护,那么您最好不使用存储库模式.但是,如果你做得对,它可以为你节省大量的冗余编码.

抽象它的原因不仅有用,因为之后您可以将NHibernate替换为另一个ORM,但由于一个名为Separation of Concerns的概念,这是一个很好的做法.您的业​​务逻辑层不应该关心或知道如何访问它使用的数据.这使得维护应用程序或其不同层更容易,这也使团队协作更容易:如果X创建数据访问层,并且Y编写业务逻辑,则他们不必详细了解彼此的工作.

公开一个IQueryable<T>是一个非常好的主意,这正是许多存储库实现正在做的事情.(我也是,虽然我更喜欢在静态类中编写它.)当然,如果你愿意,你必须公开一些插入或更新实体的方法,或者开始和提交事务的方法.(BeginTransaction应该只返回一个IDisposable以避免泄漏NHibernate接口,那就没事了.)

我可以给你一些指示:查看SharpArchitecture或FubuMVC Contrib的实现,以获得有关如何做到这一点的一些想法,这就是我解决它的方法.