c# - 混合不同数据源的存储库实现

Question

Martin Fowler 定义的存储库应该像内存中的域对象集合一样工作。这允许应用程序(理论上)忽略持久性机制。

所以在正常情况下你会有这样的东西:

public void MyBusinessLogicMethod () {
    ...
    IRepository<Customer> repository = myIocContainer.Resolve<IRepository<Customer>>();
    repository.Add(customer);
}

但是，如果您有一系列想要执行的插入/更新，并且希望在其中任何一个失败时回滚，则您需要某种 UnitOfWork 实现:

public void MyBusinessLogicMethod () {
    ...
    using (IUnitOfWork uow = new UnitOfWork()){
        IRepository<Customer> customerRepo = myIocContainer.Resolve<IRepository<Customer>>(uow);
        customerRepo.Add(customer); 

        IRepository<Order> orderRepo = myIocContainer.Resolve<IRepository<Order>>(uow);
        orderRepo.Add(order); 

        IRepository<Invoice> invoiceRepo = myIocContainer.Resolve<IRepository<Invoice>>(uow);
        invoiceRepo.Update(invoice);

        uow.Save(); 
    }
}

但是，如果您有一些奇怪的要求，即您的客户存储库针对 SqlServer 数据库，您的订单存储库针对 MySql 数据库，您的发票存储库针对 PostgreSQL 数据库，您将如何处理每个数据库 session 的事务？

现在这确实是一个人为的例子，但我遇到的每个 Repository 实现似乎都在某种程度上知道它确实是一个特定的数据库和正在使用的 ORM。

想象另一种情况，您有 2 个存储库，其中一个用于访问数据库，另一个用于调用 Web 服务。存储库的全部意义在于，应用程序不应该关心您要访问的数据源，但如果不跳过一些巨大的障碍，我不明白如何在应用程序不了解的情况下考虑这些场景“仅供引用，这是转到数据源 x，所以我们最好区别对待它。”

是否有解决此问题的模式或实现？在我看来，如果您在整个应用程序中使用 Database x 和 ORM y，那么 Repositories 工作得很好，但如果由于技术债务而偏离路线，那么 repositories 的好处将大大降低。

Answer 1

按照建议，在您的 UnitOfWork 中，您应该使用 TransactionScope 事务。在您的情况下，它会提升到 MSDTC，并确保在提交或回滚之前正确执行所有登记的操作。