.net - 工作单元 : created by/managed by Service Layer or Repository layer? C#/.NET

Question

我一直在阅读，现在已经看到了工作单元模式的两种不同实现。第一种模式让存储库与工作单元与域对象对话。



另一个实现让服务层将域对象注册为已修改:



我想我的问题是，每个人的好处/缺点是什么？我知道在不为存储库/映射器/等提供一些实现代码的情况下要回答很多问题......但总的来说，谁/什么应该真正负责“更新”UoW 然后使用它？

我的想法是，如果您让存储库处理它，它应该作为存储库的可注入(inject)接口(interface)提供，因此相同的 UoW 可以跨越多个存储库(又名，多个域对象)......

如果服务层处理它，那么每个服务层调用只有一个 UoW 实现(例如，ServiceLayer.AddCustomer(customer))，您有点“卡住”了。

在网络世界中，我看不到为不同的域对象调用多个服务层......但也许在非网络世界中我可以。

我想某些东西最终必须调用“commit()”，因此将其绑定(bind)到服务层是最有意义的。

谢谢，
麦克风

Answer 1

将 UoW 暴露给客户端通常是比使用存储库更强大的存储实现抽象，因为语义是基于状态的，而不是显式的“加载/保存/删除”操作。另一方面，明确性允许客户通过使用规范等来更好地控制线上实际发生的事情。

IMO 没有“正确”的方法，选择最合适的模式实际上取决于应用程序的数据流和持久层约束。

一些想法——

存储库通常管理单个聚合根，而 UoW 可以覆盖多个。

理想情况下，UoW 应该是持久不可知的(因为它主要处理对象状态，例如更改跟踪)。您的映射器显然会根据您的存储实现进行定制。但是其他存储问题/责任在哪里解决？存储库通常是这个问题的答案。

存储库模式可以更轻松地使用专门的语义(通过添加新方法)或调整内部实现(例如在某些场景中调用存储过程而不是在动态代码上)来扩展存储解决方案

对于具有直接和同质存储要求的应用程序，直接公开 UoW 可能是一种更简单的模型。对于更复杂的环境(例如动态 SQL 和 sprocs、遗留模式等的混合使用)，Repository 更具可维护性和可扩展性，但使用起来会受到更多限制。

这是我的头顶，希望它有帮助......