DDD：这是一个工作单元吗？
我正在尝试将 DDD 原则应用于构建在 Doctrine 2.1 之上的应用程序。为了抽象存储细节，我使用存储库作为我的聚合根，并与域签订了强有力的契约。这些存储库隐藏了所有实现细节，并且必须是我们存储或检索聚合的唯一方式。
我需要创建一个类，该类将成为存储的唯一入口点，并且仅具有以下方法：
class X
{
public function getRepository($className) {}
public function beginTransaction() {}
public function rollback() {}
public function commit() {}
}
工作单元有很多定义，虽然有些人认为它只是抽象事务的一种方式，但其他人似乎认为它是一个相当低级的对象，知道有关域对象的很多细节（Fowler定义可能更接近那个）。
那么，我的 class X 是一个工作单元，还是这个模式有另一个名称？
I'm trying to apply DDD principles to an application built on top of Doctrine 2.1. To abstract the storage details, I'm using Repositories for my Aggregate Roots, with a strong Contract with the domain. These repositories hide all the implementation details and have to be the only way we can store or retrieve aggregates.
I need to create a class which will be the only entry point to the storage, and which will only have these methods:
class X
{
public function getRepository($className) {}
public function beginTransaction() {}
public function rollback() {}
public function commit() {}
}
Unit Of Work has many definitions, and while some people think about it as just a way to abstract your transaction, others seem to consider it a quite low-level object knowing a lot of details about your domain objects (the Fowler definition is maybe closer to that).
So, is my class X a Unit Of Work, or does this pattern have another name?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
是的，您的 X 类是一个工作单元。工作单元职责通常由 ORM 实现，但我认为将其包装到您自己的工作单元类中是有优势的。这样您的应用程序代码就不会引用 ORM，从而更难绕过工作单元和存储库。
Yes, your class X is a Unit Of Work. Unit Of Work responsibilities are usually implemented by ORM but I think that there is an advantage in wrapping it into your own Unit Of Work class. So that your application code does not have a reference to ORM making it harder to bypass Unit Of Work and Repositories.