如果我正确理解工作单元模式，它基本上聚合所有数据存储调用，以便它们在一个'事务'中执行，无论是sql事务还是你手工编写的事情。< / p>
我的问题是你能实现一个命令模式来实现同样的目标吗？例如，在业务层中，您将拥有诸如CreateUserAction或CreateOrder之类的操作，这些操作可能会触发多个表以便成功执行操作。与UoW不一样吗？
答案 0 :(得分：1)
是的，命令可以封装整个工作单元。然而，并非所有命令显然都这样做，并且如上所述，您可以拥有一系列共享相同工作单元的命令。
这实际上取决于命令的粒度以及尝试完成的内容。
答案 1 :(得分：0)
如果我理解正确的单位工作模式，基本上 聚合所有数据存储调用，以便它们在一个中执行 'transaction'，无论是sql事务还是某事 你是手写的。
UnitOfWork不会聚合数据存储调用。它没有任何方法来实现应用程序的任何业务逻辑。
UnitOfWork应该有跟踪更改的方法，您的应用程序会对数据库进行更改，以便所有这些更改都可以在单个事务中应用。
传统上，我们通过更改模型的字段来更改数据库。因此，UnitOfWork看起来像this。
我的问题是你能否实现一个命令模式来实现 相同？例如，在业务层中，您将拥有操作 例如，CreateUserAction或CreateOrder，可能会打几个 表格，以便成功执行操作。不是那个 与UoW相同？
在我看来，这不是UnitOfWork。这只是一个命令模式，它直接更改数据库。您的行为只能被执行。它们不会被跟踪更改（没有干净/脏状态），它们不能被删除。对于数据库更改Queue，您看起来像Commands。
要让UnitOfWork您的命令参与，可以创建商务逻辑模型的实例，然后将这些模型传递给registerNew()的{{1}} / registerDirty()方法。
答案 2 :(得分：0)
我们目前批量发布命令（例如，在用户点击保存之前创建的所有命令），并且只有在批处理结束时，我们才会验证受影响的实体，并且只有在验证成功时才会保留它们。因此，我们实现了命令集的事务完整性，不需要回滚，因为如果验证失败，我们根本不会持久化（对于EF，我们不会在上下文中调用SaveChanges（））。