我一直在阅读，现在已经看到了工作单元模式的两种不同实现。第一种模式让存储库与工作单元与域对象对话。
另一个实现是服务层将域对象注册为已修改：
我想我的问题是，每种方法的优点/缺点是什么？我知道在不为存储库/映射器/等提供一些实现代码的情况下要回答很多问题......但总的来说，谁/什么应该真正负责“更新”UoW，然后使用它？
我的想法是，如果您让存储库处理它，它应该作为存储库的可注入接口提供，这样同一个 UoW 就可以跨越多个存储库（也就是多个域对象）...
如果服务层处理它，那么您有点“卡住”，每次服务层调用只有一个 UoW 实现（例如，ServiceLayer.AddCustomer(customer)）。
在网络世界中，我看不到为不同的域对象调用多个服务层......但也许在非网络世界中我可以。
我想有些东西最终必须调用“commit()”，所以将它绑定到服务层是最有意义的。
谢谢， 迈克
【问题讨论】：
标签： .net design-patterns unit-of-work
将 UoW 公开给客户端通常是比使用存储库更强大的存储实现抽象，因为语义是基于状态的，而不是显式的“加载/保存/删除”操作。另一方面，明确性允许客户通过使用规范等更好地控制线上实际发生的事情。
IMO 没有“正确”的方法，选择最合适的模式实际上取决于应用程序的数据流和持久层约束。
一些想法-
一个存储库通常管理一个聚合根，而一个 UoW 可以覆盖多个。
理想情况下，UoW 应该与持久性无关（因为它主要处理对象状态，例如更改跟踪）。您的映射器显然会根据您的存储实现进行定制。但是其他存储问题/责任在哪里解决？存储库通常是这个问题的答案。
存储库模式可以更轻松地使用专用语义（通过添加新方法）或调整内部实现（例如在某些场景中调用存储过程而不是动态代码）来扩展存储解决方案
李>对于具有直接和同质存储要求的应用程序，直接公开 UoW 可能是一种更简单的模型。对于更复杂的环境（例如动态 SQL 和存储过程、遗留模式等的混合使用），Repository 更易于维护和扩展，但使用起来更受限制。
这不是我的想法，希望对您有所帮助......
【讨论】：
即使在第一种情况下，您的 UnitOfWork 也很可能是一个单例（每个线程），因此即使 CustomerRepository 和 OtherBoilerplateExampleRepository 在调用提交之前都访问了 UnitOfWork，提交仍将使用所有人所做的所有更改存储库。
话虽如此，我认为第一种模式是更简洁的方式。第二种方式是说 CustomerService 必须同时操作业务对象和向 UnitOfWork 注册更改。这有点违反关注点分离。此外，这些示例中未显示，但存储库模式也提供了缓存数据对象的位置。
就注入依赖项而言，我认为与其使 UoW 成为可注入接口，不如使 Mapper 模式（您在第二个示例中看到，但大概在第一个示例中暗示）可注入是更合适的选择。无论您使用的是 SQL DB、XML 文件等，UoW 事务管理功能都应该保持不变。
【讨论】：