Удалить зависимость от контейнера IoC

Question

Прочитав все больше и больше о контейнерах IoC, я прочитал в этом посте о том, что в вашем коде нет IoC.Resolve () и т.д.

Мне действительно интересно узнать, как я могу удалить зависимость от контейнера?

Я хочу написать код, подобный следующему:

public void Action()
{
    using(IDataContext dc = IoC.Resolve<IDataContext>())
    {
        IUserRepository repo = IoC.Resolve<IUserRepository>();
        // Do stuff with repo...
    }
}

Но как мне избавиться от вызовов IoC.Resolve? Может быть, мне нужно лучшее понимание DI ...

Заранее спасибо.

Answer 1

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

// In Presentation.csproj
class PresentationController
{
    public PresentationController(IDataContextFactory dataContextFactory, IRepositoryFactory repositoryFactory)
    {
        #region .NET 4 Contract
        Contract.Requires(dataContextFactory != null);
        Contract.Requires(repositoryFactory != null);
        #endregion

        _dataContextFactory = dataContextFactory;
        _repositoryFactory = repositoryFactory;
    }

    private readonly IDataContextFactory _dataContextFactory;
    private readonly IRepositoryFactory _repositoryFactory;

    public void Action()
    {
        using (IDataContext dc = _dataContextFactory.CreateInstance())
        {
            var repo = _repositoryFactory.CreateUserRepository();
            // do stuff with repo...
        }
    }
}

// In Factories.API.csproj
interface IDataContextFactory
{
    IDataContext CreateInstance();
}

interface IRepositoryFactory
{
    IUserRepository CreateUserRepository();
    IAddressRepository CreateAddressRepository();
    // etc.
}

// In Factories.Impl.csproj
class DataContextFactory: IDataContextFactory
{
    public IDataContext CreateInstance()
    {
        var context = IoC.Resolve<IDataContext>();
        // Do any common setup or initialization that may be required on 'context'
        return context;
    }
}

class RepositoryFactory: IRepositoryFactory
{
    public IUserRepository CreateUserRepository()
    {
        var repo = IoC.Resolve<IUserRepository>();
        // Do any common setup or initialization that may be required on 'repo'
        return repo;
    }

    public IAddressRepository CreateAddressRepository()
    {
        var repo = IoC.Resolve<IAddressRepository>();
        // Do any common setup or initialization that may be required on 'repo'
        return repo;
    }

    // etc.
}

Преимущество этого подхода заключается в том, что вы не можете полностью исключитьСама зависимость IoC, вы можете инкапсулировать ее в один тип объекта (фабрика), отделяя основную часть вашего кода от контейнера IoC.Это повышает гибкость ваших кодов в свете, скажем, переключения с одного контейнера IoC на другой (т. Е. Виндзор на Ninject).

Следует отметить, что интересным следствием этого является то, что ваши заводы обычно вводятся вих иждивенцы по той же самой структуре IoC, которую они используют.Например, если вы используете Castle Windsor, вы создадите конфигурацию, которая скажет контейнеру IoC внедрить две фабрики в ваш бизнес-компонент при его создании.У самого бизнес-компонента также может быть фабрика ... или он может быть просто введен той же самой платформой IoC в компонент более высокого уровня и т. Д. И т. Д., Ad inf.

Answer 2

Я недавно писал об этой самой проблеме:

• Как я использую контейнеры IoC
• Извлечение из контейнера

Answer 3

Одна альтернатива - переписать метод для приема Func<T> делегатов.Это удаляет зависимость из метода и позволяет вам тестировать его с макетом:

Answer 4

Я недавно был над проектом, который не остановился на контейнере IoC. Они справились с неопределенностью, запретив не-IoC-особенности своего контейнера, а также добавив Resolve в свой собственный класс. Это также то, что я видел несколько раз в сообщениях в блоге ... убрать последнюю зависимость, зависимость от контейнера внедрения зависимости.

Это работоспособный метод, но в какой-то момент вы должны выбрать инструменты, которые вы используете, и согласиться с тем, что вы заплатите за переход на альтернативные инструменты. Для меня контейнеры IoC попадают в категорию вещей, которые вы, вероятно, должны охватить всем сердцем, поэтому я подвергаю сомнению этот уровень факторинга. Если вы хотите изучить это дальше, я предлагаю следующую ссылку:

http://blog.objectmentor.com/articles/2010/01/17/dependency-injection-inversion

Answer 5

Есть второй инжектор зависимостей для ввода первого, а первый - для второго.