如果我正确理解工作单元模式,它基本上聚合所有数据存储调用,以便它们在一个'事务'中执行,无论是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())。