Question

我实现了一个持久性无知的存储库模式。存储库实现仅与我的实体对象IUnitOfWork和ITable<T>接口进行交互。目的是IUnitOfWork不会被重用，而是代表一个单一的交易。到目前为止，我已经实现了内存以及IUnitOfWork和ITable<T>的Linq-to-Sql版本。

我的问题是，由于IUnitOfWork注入存储库，我最终需要知道如何在使用存储库的情况下实例化新的IUnitOfWork。由于这是应该可插拔的主要部分，感觉就像我做错了什么。一般使用模式是这样的：

FooUnitOfWork unitOfWork = new FooUnitOfWork();
Repository repos = new Repository(unitOfWork);
// ...act upon repos
unitOfWork.Save();

现在看来我需要一些其他模式来允许应用中的每个存储库使用来获得正确的工作单元（例如内存，L2S等）。

最合适的模式是什么？我看过Fowler's discussion on the topic，但他的例子似乎都不合适。我已经感觉到我拥有的抽象量超过了我想要的数量，因此建立另一个间接似乎过度。

目前，我倾向于某种应用程序范围的提供程序，可以将其配置为生成正确的IUnitOfWork。我是偏离基础的还是真正实现不可知所需的东西？

Answer 1

更新：虽然这并没有真正打破它最终只是生产一个穷人的IoC容器。我最终只是替换了所有这些：

UnitOfWorkFactory.Create();

使用广义Common Service Locator实现：

Microsoft.Practices.ServiceLocation.ServiceLocator.Current.GetInstance<IUnitOfWork>();

这使我能够创建一个使用依赖注入的库，而不会强制所有用户使用相同的IoC框架。

也许我应该使用一个非常简单的工厂来设置回调？它可以有一组静态方法，如下所示：

public static class UnitOfWorkFactory
{
    private static Func<IUnitOfWork> FactoryMethod;

    public static IUnitOfWork Create()
    {
        if (UnitOfWorkFactory.FactoryMethod == null)
        {
            throw new InvalidOperationException("...");
        }

        return UnitOfWorkFactory.FactoryMethod();
    }

    public static void SetFactoryMethod(Func<IUnitOfWork> factory)
    {
        UnitOfWorkFactory.FactoryMethod = factory;
    }
}

这会在哪里崩溃？

Answer 2

我建议使用访问者模式来发现工作单元界面的实现。

[UnitOfWork(Name="foo")]
public class FooUnitOfWork : IUnitOfWork {}

Repository repo = new Repository("foo");
//stuff happens
repo.Save(); //or repo.Worker.Save();

在repo实例中，发现工厂找到工作者并创建它。

找到IUnitOfWork的设计模式是什么？

2 个答案: