工作单元、存储库、上下文
如果您查看这个问题 我对下一步有疑问。
假设您有两个生成项目和子项目的存储库。我还有一个 UnitOfWork，它充当对（在这个简单的情况下）两个不同项目的更改的上下文。
似乎有几种生成 UnitOfWork 的方法，有时将其注入存储库，有时可以由工厂生成（然后注入或从工厂检索）。
我的问题是 UnitOfWork 如何通知存储库现在要提交它的更改吗？
我想我可以让存储库订阅 UnitOfWork 上的事件以进行提交/回滚。
第二个问题，工作单元的想法是，如果我有这个权利的话，可以协调更新。使用我的 Item 和 SubItem 示例（一个 Item 有多个 SubItems），UnitOfWork 会对此进行协调，因此首先写入 Item 允许写入 SubItem？现在我似乎需要工作单元来了解存储库这似乎是错误的
。
If you take a look at this SO question I have a question on the next step.
Imagine you have two repositories generating Items and SubItems. I also have a UnitOfWork which acts as a context for changes to the (in this simple case) two different items.
There seem to be a few ways of generating a UnitOfWork, sometimes this is injected into the repository, sometimes this can be generated by a factory (and then either injected or retrieved from the factory.
My question is how does the UnitOfWork notify the repositories that its changes are now to be committed?
I guess I can have the repository subscribe to events on the UnitOfWork for commit/rollback.
Second question, the idea of the unit of work is, if I have this right, to co-ordinate updates that may conflict. Using my example of Item and SubItem (an Item has a number of SubItems) the UnitOfWork coordinates this so the Item is written first allowing the SubItem to be written? Now I seem to need the unit of work to know about the repositories which seems wrong.
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我构建存储库的方式是让 UnitOfWork 只是一个“令牌”，由 Repo 上的 BeginUnitOfWork() 方法生成，然后必须将其传递给 Repo 上进行数据库调用的几乎任何其他方法。从概念上讲，它必须知道如何做的唯一一件事就是进行处置，当这种情况发生时，会导致与该 UOW 关联的 NHibernate 会话关闭。它通过向 Repo 中的受保护方法授予委托来实现此目的，然后在其 Dispose 方法中回调该委托。这对我来说完全抽象了实际的数据访问机制；无论后端如何，我都可以实现相同的模式，并且该模式的用户无法破解 UnitOfWork 来获取实际的数据访问机制。
YMMV；它确实要求需要执行数据库对象的类依赖于存储库以及工作单元。您可以使用其他委托来公开 UnitOfWork 本身的方法，使其成为唯一的依赖项。
The way I structured my repository was to have the UnitOfWork simply be a "token", spawned by a BeginUnitOfWork() method on the Repo, that then had to be passed to pretty much any other method on the Repo that made DB calls. The only thing it has to know how to do, conceptually, is be disposed, which when that happens causes the NHibernate session associated with that UOW to be closed. It does this by being given a delegate to a protected method in the Repo that it then called back in its Dispose method. What this does for me is completely abstract the actual data-access mechanism; I can implement the same pattern regardless of the back end, and users of the pattern cannot hack the UnitOfWork to get at the actual data-access mechanism.
YMMV; it does require classes that need to perform DB objects to be dependent on the repository as well as the unit of work. You could use additional delegates to expose methods on the UnitOfWork itself that would allow it to be the only dependency.