[DI] Resolve типа внутри метода контроллера (ASP.MVC). Как реализовать?

Question

[no0ob]

Доброго времени суток.
В моем проекте есть куча разных репозиториев и их интерфейсов. В методе контроллера хотелось бы получать реализацию конкретного репозитория следующим образом:

public ActionResult SomeMethod(){
   var someRepo = ObjectFactory.Resolve<ISomeRepository>();
   return Content(someRepo.SomeAction());
}

В интернете много информации о различных DI контейнерах (Ninject, Unity ...). Проблема в том, что они резолвят параметры конструктора. Я думал использовать Unity таким образом, как писал выше, но наткнулся на эту ссылку unity.codeplex.com/discussions/640841, где говорится, что так использовать Unity нехорошо.
Существуют ли какие-нибудь готовые решения, позволяющие резолвить типы внутри метода контроллера (желательно с возможностью настройки через XML, как в Unity)?

Comments

[Maa-Kut]

А зачем резолвить зависимости вручную, если можно переложить эту работу на фабрику контроллеров? И пусть себе зависимости втягиваются через параметры конструктора, нет в этом криминала.

[Iron Bug]

А вы уверены, что они резолаят только из конструктора? Вот простенький tinyioc умеет, то о чем вы говорите. Я думаю и остальные должны уметь. https://github.com/grumpydev/TinyIoC/wiki/Resoluti...

[Толстый Лорри]

Iron Bug: как вы под это будете писать тесты?) Конечно, инжектить через конструктор, скажем, в фильтры не получится, но это инфраструктурный элемент, там иначе никак, но зачем в контроллере извращаться, когда есть возможность?

[Iron Bug]

Free_ze: вы про то, что резолвится тип, а не интерфейс? Ну так можно резолвить и по интерфейсам

[Толстый Лорри]

Iron Bug: Нет, я про то, что используя DI через сервис-локатор/фабрику мы не сможем взять сферический в вакууме объект контроллера и написать для него тест, просто передав что-то тестовое в конструктор, ведь нам придется тащить туда еще и IoC-контейнер / имитицию фабрики.

Answer 1

[Толстый Лорри]

DependencyResolver.Current.GetService(typeof(IMyService))

Comments

[Толстый Лорри]

В MVC лучше сделать враппер для вашего любимого IoC-контейнера, реализующий IDependencyResolver и подключить его в фреймворк. Как это делать можно почитать здесь: smarly.net/pro-asp-net-mvc-4/introducing-asp-net-m... , начиная с "Установка MVC DI"

Answer 2

[Валерий Абакумов]

Существуют ли какие-нибудь готовые решения, позволяющие резолвить типы внутри метода контроллера (желательно с возможностью настройки через XML, как в Unity)?

Добрый день!
Если Вы пытаетесь резолвить что-то из IoC-контейнера в методе действия, значит, Вы идете по не совсем правильному пути (т.к. резолвить напрямую из контейнера приводит к значительным утечкам памяти из-за того, что GC не может их очистить, т.к. они "используются" самим IoC-контейнером). Что мешает Вам передавать Ваш ISomeRepository в конструктор контроллера и записывать его в private field?

Я бы делал так, как предложил Free_ze в комментариях к Вашему вопросу:

1. Пишем фабрику контроллеров (или подключаем готовую, если она есть в комплекте с IoC-контейнером)
   
2. Вставляем интерфейсы в конструкторы контроллеров
   

Контроллер будет выглядеть в этом случае так:

private readonly ISomeRepository _someRepo;
public MyController(ISomeRepository someRepo)
{
    if(someRepo == null)
        throw new ArgumentNullException(nameof(someRepo));
    _someRepo = someRepo;
}

Дальше используем _someRepo как душе будет угодно. Такой подход более правильный с точки зрения разрешения зависимостей. Про IoC-контейнер, по сути, должен знать только тот, кто его конфигурирует.

P.S. Бонус: если у Вас много репозиториев и интерфейсов для них, значит, настала пора рефакторинга. Смотрите в сторону GenericRepository + UnitOfWork.