为什么我要在 NHibernate 会话之上使用工作单元模式?
我什么时候会在 NHibernate 已经提供的基础上编写 UoW 实现? 有现实世界的例子吗?
When would I write a UoW implementation on top of what is already provided by NHibernate? Any real world examples?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
您所描述的工作单元已经由 NHibernate 提供,因此没有理由执行这样的工作单元。
我们在 WCF 服务中拥有的是更高级别的工作单元,其中包含对我们当前工作单元的应用程序很重要的信息。 这包括为我们抽象 NHibernate ISession。 当您将其分解时,您会得到适合三个类别
需要处理工作单元的代码。 谁支持工作单元并不重要。 它可以是 NHibernate、iBatis 或自定义 ORM。 所有代码需要做的就是加载、回滚、保存等。它不也不应该关心用于执行此操作的机制。
需要直接处理 ISession 的代码,因为它正在执行 NHibernate 特定的操作。 通常这与需要创建的复杂查询有关。
不需要知道它正在工作单元中运行或访问 ISession。 作为讨论的一部分,我们可以完全忽略这一点。
虽然 1. 中的代码只能针对 ISession 工作,但我们的偏好是尝试抽象出代码中我们无法直接控制或可能更改的内容。 其价值有两个原因。
当我们开始时,我们并没有 100% 相信 NHibernate。 我们正在考虑 iBatis 或定制的东西。 显然这不再是问题。
整个团队都不是 NHibernate 专家,我们也不希望他们成为专家。 大多数情况下,人们编写的代码都属于第一类,他们所知道的就是我们的工作单元。 当类别 2 中的代码必须编写时,它是由团队中熟悉 NHibernate 的人员编写的。
因此,最后我想说的是,您所讨论的工作单元类型是不需要的,我建议更高级别的工作单元可以提供很多价值。
The Unit Of Work you are describing is already provided by NHibernate so there is no reason to do such a unit of work.
What we have in our WCF Service is a higher level unit of work that contains information important in our application for the current unit of work. This includes abstracting the NHibernate ISession for us. When you break it down you have code that fits into three categories
Code that needs to deal with a Unit Of Work. It doesn't matter who backs the unit of work. It could be NHibernate, iBatis or a custom ORM. All the code needs to do is Load, Rollback, Save, etc. It doesn't nor should it care about the mechanism used to do so.
Code that needs to deal with an ISession directly because it's doing NHibernate specific things. Usually this has to do with complex queries that need to be created.
Doesn't need to know that it's running in a Unit Of Work or access the ISession. We can completely ignore this as part of this discussion.
While code in 1. could just work against an ISession our preference is to try to abstract away things in the code that we do not directly control or that could change. This has value for two reasons.
When we started we weren't 100% sold on NHibernate. We were considering iBatis or something custom. Obviously this is no longer an issue.
The entire team are not experts in NHibernate nor do we want them to be. For the most part people write code that fits into category 1. and all they know about is our Unit Of Work. When code in category 2. has to get written it gets written by the people on the team that understand NHibernate well.
So to close I would say that the type of Unit Of Work you are talking about is not needed I would suggest that a higher level Unit of Work can provide a lot of value.
我的基本工作单元界面包含以下方法
- 初始化
- 犯罪
- 回滚
- IDisposable.Dispose
我将它用于会话和事务管理。
它很有用,因为我不必为不同的会话范围一次又一次地编写该代码。 (每个请求、每个请求系列、每个线程的工作单元等)
My basic unit of work interface contains the following methods
- Initialize
- Commit
- Rollback
- IDisposable.Dispose
I use it for both session and transaction management.
It is useful because I don't have to write that code again and again for different session scopes. (unit of work per request, per series of requests, per thread, etc)
如果您正确设置了所有映射(即级联),则无需执行任何特殊操作,
ISession
就可以正常工作。 但是,如果您正在编写 3 层应用程序,则必须手动对要在单个事务中执行的数据库操作进行排序。 Fowler 在《企业应用程序架构模式》中的“参考实现”可以作为一个很好的起点:Provided you set up all your mappings correctly (i.e. cascades), you don't have to do anything special and
ISession
will do just fine. However, if you're writing a 3-tier application, you'll have to manually sequence database operations you want to be performed in a single transaction. Fowler's "reference implementation" in "Patterns of Enterprise Application Architecture" can be a good starting point: