存储库模式、UoW 模式、普通 NHibernate 会话
关于Repository 模式
、UoW 模式
的使用有很多讨论。我非常理解何时以及为何使用存储库模式
。 假设我有几个聚合根。接下来怎么办?我更喜欢什么模式/实现?使用比普通 NHibernate Session 更复杂的解决方案的原因是什么?
谢谢!
There are many discussions about use of Repository pattern
, UoW pattern
. I quite understand when and why Repository pattern
is used.
Let's just say I have several aggregate roots. What's next? What pattern/implementation do I prefer? What are the reasons to use more complex solutions than plain NHibernate Session?
Thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
存储库模式是一种抽象,恕我直言,并非不必要。它只是允许您预定义可以在整个系统中多次使用的某些查询,并且它提高了可读性。
存储库使用工作单元(已由 NHibernate 的 ISession 实现);这就是我的观点。
我要做的是在 NHibernate 的 ISession 上为您的项目创建一些扩展方法;它看起来像这样:
然后,在您的代码中,您可以执行以下操作:
Repository pattern is an abstraction that is -imho- not unnecessary. It just allows you to predefine certain queries that can be used multiple times throughout the system, and, it improves readability imho.
The repository uses the unit-of-work (which is already implemented by NHibernate's
ISession
); that's my point of view.What I would do, is create some extension methods on NHibernate's ISession for your project; which can look like this:
Then, in your code, you can do this:
存储库模式出现在 NHibernate 之前。现在我们在 NHibernate 之上应用存储库模式,这在大多数情况下是不必要的抽象。通用存储库作为 NHibernate 之上的抽象层背后的想法是,在某些时候您可以切换到其他持久机制,例如实体框架。真的吗?这可能吗?我认为不会,因为你最终会遇到很多 NH 细节,例如缓存、获取等。对我来说,简单的 Session 使用就可以了。
这里ayende 谈论了一会儿
还有更多...
Repository pattern is before NHibernate. Now we apply repository pattern on top of NHibernate which is unnecessary abstraction in most cases. The idea behind a generic repository as an abstraction layer over NHibernate is that at some point you can switch to other persisting mechanism like Entity Framework. Really? Is that possible? I think not, because you will end up with so many NH specifics like caching, fetching etc. For me plain Session usage is OK.
Here ayende talks about that for a while
And more...