我正在尝试构建一个遵循存储库和工作单元模式的系统，以允许持久性无知/单元测试等。我正在寻找有关处理Rollback的建议。理想情况下我想使用POCO，但我想我可能至少需要实现一个接口来提供一些零碎的东西。
因此，假设我们有两个存储库，一个上下文/工作单元。
我添加一项，修改另一项并删除第三项。重复第二个存储库，然后我调用rollback。
在过去，我使用类似于DataSet的东西。每个对象都有pendingNew，pendingAmended，pendingDeleted，clean状态。还有一个用于回滚的副本的最后一个持久化版本。
你会如何实现这个？
编辑：
好的，这就是我认为我实际上正试图解决的问题。准备好图案：）
最终该项目是WPF MVVM。因此，我们正在将模型看到商店所在的位置。
我想我一直在尝试将模型与存储库的想法混为一谈，因为我认为模型应该使用UOW和存储库来提供模型需要提供的功能。这听起来更好吗？
我想要完全持久性无知，所以想象一下我的域名包括客户，订单和OrderLines。
GUI假设有一个按钮新订单，允许用户填写客户详细信息，订单详细信息和1-n OrderLine详细信息。他点击保存，他们进入数据库，他点击取消他们没有。
因此，在这种情况下，模型可能会向CustomerRepository询问客户，然后是OrderRepository以获取新订单，然后是每个新行的OrderLineRepository，然后告诉工作单元保存它们。
听起来合理吗？这对我来说，我认为这是分离的定义。我很想在模型和存储库之间使用另一个API。不，那太傻了。
编辑2：这是一篇很好的文章，有点helped。
答案 0 :(得分：6)
我设计了我的工作单元和存储库类，类似于它所描述的here on MSDN。 IUnitOfWork类的基本思想是它处理所有数据库工作本身。
然后我（我的IUnitOfWork类和实现）添加了BeginTransaction()方法，该方法打开TransactionScope()对象，然后添加了EndTransaction(bool commit)方法。此方法通过将事务提交到数据库（如果为true）或回滚事务（如果为false）来处理关闭事务。
这允许我控制复杂的事务，允许回滚多个提交。
修改： 我的想法是你希望你的UnitOfWork对象知道存储库，而不是相反。这是我的看法，你会发现喜欢相反的人，但这就是原因。
当您想以某种方式处理数据库时，您希望它受当前工作单元的约束。因此，对我而言，通过工作单元访问您的存储库是合乎逻辑的，而不是让您的存储库访问您的工作单元。
如果您需要分支并在不同的数据库上执行多项操作（例如，如果历史数据写入与实时数据不同的数据库，或者您正在进行水平数据库分区），它也会更容易数据库将拥有自己的工作单元。原因是如果您使存储库知道工作单元，您需要为每个数据库创建一个工作单元，以及您可能需要访问它的每个工作单元所需的每个存储库的副本。
最后，保持对您的存储库的访问只能通过您的工作单元访问，这使得开发人员可以简化API。对于初学者，您只需要实例化1个对象（工作单元）而不是1个工作对象单元加上您可能需要的许多存储库对象。它使您的代码保持简单（imho），并使开发人员更容易出错。
答案 1 :(得分：2)
如果没有更多细节，很难肯定地说，但我会考虑从IDbConnection接口和相关接口实现。它为您提供了一个界面，大多数具有任何经验的C＃编码器都会熟悉。
老实说，如果你的存储机制，它真的取决于效率。如果它有效地处理了大量的更改，那么你可能最好让你的回滚机制构建一个应该执行回滚的操作列表，这在“提交”中被丢弃。另一方面，如果更新很昂贵，那么您的事务机制是否维护要在提交时执行的操作列表，这些操作在回滚时将被丢弃。您还需要考虑其他代码是否应该在提交之前看到更新;他们将采用前一种方法，而后者则不会。
答案 2 :(得分：0)
我会通过使用像NHibernate或Entity Framework这样的框架来实现这一点。 :) NHibernate允许您使用POCO，并为您完成所有管道工作。