Architecture 使用多个数据源的工作单元？

有可能（甚至有可能）我只是没有完全摸索“工作单元”的概念。基本上，我认为它是一种在面向对象环境中使用的广泛事务。启动工作单元、与对象交互、提交或回滚。但这如何分解为这些对象后面的数据存储上的实际事务呢

在一个只有一个DB和一个ORM（如NHibernate）的系统中，这很容易。事务可以通过ORM进行维护。但是，如果自定义域模型掩盖了许多不同的数据源，那么系统会怎么样呢？不是所有这些数据源都是关系数据库吗？（在这附近的文件系统上做了很多工作。）

现在我一直认为“不能在同一个‘原子’业务操作中跨SQL2005 DB、SQL2000 DB、DB2 DB和文件系统维护事务。”因此，现在这是团队中开发人员的责任（他们通常独立工作）在代码中手动维护事务。每个数据库上都可以有适当的事务，但整个业务操作在过程中的每一个重要步骤都需要手动检查和平衡

然而，随着领域复杂性的增加和标准开发人员的流动，随着时间的推移，这种方法将变得越来越困难和容易出错

有没有人有任何建议或例子来说明如何最好地解决这样一个领域，或者以前是如何解决的？在这种情况下，实际的“域”仍处于非常初级的阶段，作为一个原型，有一天会扩展和消费/替换一个由不同遗留应用程序组成的大型生态系统。因此，有足够的空间进行重新设计和重新考虑

作为参考，我目前目标设计的10000英尺视图是：一个大集合，尽可能小的、愚蠢的客户端应用程序调用一个基于中心消息的服务。该服务是进入“域核心”的入口，可以被认为是一个大的MVC风格的应用程序。向服务发出请求（很像“操作”），由处理程序（很像“控制器”）接收。任何程序性的东西都会去那里。它们与包含所有业务规则的模型交互。模型发布事件，监听器（“服务”？这部分在设计中仍然不明确，有待改进）通过与存储库（数据库x、数据库y、文件系统、电子邮件、任何外部资源）交互来拾取和处理这些事件。所有人都高兴地这样做

---

很抱歉说得这么冗长：）但如果有人有什么建议，我很乐意听听。甚至（特别是）如果建议是“你的设计不好，试试这个…”谢谢

我以前工作过一个可以实现这一点的系统，它相当简单。因为您的项目正处于早期阶段，所以这可能是对您有用的信息。不幸的是，我不再能够访问该代码，但我仍然能够轻松地描述它是如何工作的

我所做的是使用通用存储库模式实现构建存储库。基本存储库类型始终是服务和UoW的引用。为了便于讨论，我们将其称为BaseRepository。“T”将仅限于表示域对象的IEntity实现。在BaseRepository中，我创建了另一组用于合成的基类，如SqlBaseRepository、XmlBaseRepository等

UoW只关心BaseRepository类型的东西，这是核心功能存在的地方。将表示（CRUD的）基本CUD，为创建、更新和删除提供等价物。每种方法都将创建一个委托，并将其放置在UoW内的队列中，同时传递关于该委托将是什么类型的事务的信息以及完成该委托所需的适当数据。UoW将开始维护事务中需要涉及哪些存储库的列表，但仍然不关心它是什么类型。有效地说，在这里排队就像在事务中登记一样

BaseRepository定义了一个名为.ApplyChange（）的抽象方法。一旦对UoW调用了.Commit（），它将创建一个TransactionScope（），并开始调用列表中的delagates，将信息传递回.ApplyChange（）。.ApplyChange（）的实际实现存在于特定的存储库库中，即SqlRepositoryBase等，并且也可以被实现覆盖

至少对我来说，事情变得棘手的地方是倒退。我只处理一个数据库，但有时会进行基于文件的更改。我添加了一个.RevertChange（）方法，并开始跟踪原始状态和修改后的状态，以便基本上可以应用反向增量返回到文件堆栈上的位置

我希望我能更具体地介绍实现，但我现在已经一年多没有看到代码了。我可以告诉你，原始代码的基础来自蒂姆·麦卡锡的书。我的大量存储库实现都基于他的示例，我的大部分定制都来自UoWs及其实现

---

我希望这能有所帮助！：-）

您是否研究过分布式事务协调器@Michael-我很幸运地将TransactionScope/MSDTC与SqlServer专用解决方案结合使用。跨越文件系统和其他RDBMS可能更为棘手。OP正在讨论协调各种db引擎的工作，所以我不建议使用MSDTC作为答案。实际上，这非常有用。老实说，我认为从长远来看，推荐书将是最有帮助的部分。也许是我放慢修修补补的脚步，赶上阅读的时候了。我可能在现场