Какой шаблон дизайна, чтобы найти мой IUnitOfWork? - PullRequest
Новая
       72

Какой шаблон дизайна, чтобы найти мой IUnitOfWork?

1 голос
/ 31 августа 2009

Я реализовал шаблон хранилища с постоянным невежеством. Реализация репозитория взаимодействует только с объектами моей сущности, IUnitOfWork и ITable<T> интерфейсами. Предполагается, что IUnitOfWork не используется повторно, а представляет собой одну транзакцию. До сих пор я реализовал в памяти, а также версии Linq-to-Sql IUnitOfWork и ITable<T>.

Моя проблема заключается в том, что из-за внедрения IUnitOfWork в хранилище у меня возникает необходимость узнать, как создать новый IUnitOfWork там, где когда-либо используется хранилище. Поскольку это основной элемент, который должен быть подключаемым, создается впечатление, что я сделал что-то не так. Общая схема использования выглядит примерно так: 

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

Теперь кажется, что мне нужен какой-то другой шаблон, чтобы разрешить каждому использованию хранилища в приложении для получения правильной единицы работы (например, в памяти, L2S и т. Д.).

Каков наиболее подходящий для этого шаблон? Я смотрел на дискуссию Фаулера по теме , но ни один из его примеров, похоже, не подходит. Я уже чувствую, что количество абстракции, которое у меня есть, больше, чем мне бы хотелось, поэтому построение еще одной косвенности кажется чрезмерным.

В данный момент я склоняюсь к какому-то провайдеру для всего приложения, который можно настроить для получения правильного IUnitOfWork. Я неосновный или это то, что нужно, чтобы быть действительно независимым от реализации?

Ответы [ 2 ]

1 голос
/ 31 августа 2009

Обновление: , хотя это на самом деле не сломалось, в итоге получился IoC-контейнер для бедняков. В итоге я просто заменил все это: 

UnitOfWorkFactory.Create();

с обобщенным Common Service Locator реализация: 

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

Это позволило мне создать библиотеку, которая использует Dependency Injection, не заставляя всех пользователей использовать одну и ту же инфраструктуру 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;
    }
}

Где это ломается?

0 голосов
/ 31 августа 2009

Я бы предложил использовать шаблон Vistor для обнаружения реализаций интерфейса IUnitOfWork. 

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

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

Внутри репозитория фабрика обнаружения находит работника и создает его.

...