Преимущества разрешения зависимостей и IoC в asp.net mvc
Возможный дубликат:
Зачем мне нужен контейнер IoC, а не простой DI-код?
Я прочитал несколько статей на эту тему, и я не нашел никаких блестящих преимуществ. Например этот код:
//some action in a controller
//simplest solution:
var repository = new EmployeeRepository();
var model = repository.ListAllEmployees();
хорошо вы можете сказать: в этом решении контроллер / действие очень сильно зависит от EmployeeRepository. Разрешение зависимости:
var repository = DependencyResolver.Current.GetService<IEmployeeRepository>();
var model = repository.ListAllEmployees();
Я не нашел его лучше, чем следующий без разрешения зависимостей / ioc:
var model = Managers.EmployeeManager.ListAllEmployees();
Надеюсь, что кто-то может дать мне некоторые идеи / ссылки / сообщения на эту тему.
2 ответа
Ваш пример с DependencyResolver не намного лучше, чем ваш исходный код, так что да... в этом нет особого преимущества.
К счастью, это не так, как вы должны это сделать. Вместо этого вы используете конструктор или внедрение свойства.
Я согласен с @adriaanp: более простое модульное тестирование - это только побочное преимущество внедрения зависимостей. Самым большим преимуществом является то, что он поощряет архитектуру без зависимости Ваши классы автономны и не зависят от конкретной реализации (кроме ее интерфейса и требований)
Другое преимущество заключается в том, что контейнер IoC может контролировать время жизни ваших зависимостей. Предположим, вы хотите, чтобы объект существовал в течение всего срока действия запроса на веб-странице. Также предположим, что вы хотите получить доступ к этому объекту во многих разных классах. Вы можете создать объект в событии загрузки страницы, а затем передать его каждому создаваемому объекту, который в этом нуждается. Однако это может означать, что вам нужно передать его объектам, которые на самом деле его не используют, просто потому, что они создают объекты, которые в этом нуждаются (или они создают объекты, которые создают объекты, которые в этом нуждаются, или... и т. Д.).
С помощью внедрения зависимостей и контейнера IoC контейнер управляет временем жизни объекта и занимается внедрением его в объекты, которые в нем нуждаются. Вам не нужно встраивать это в свои проекты. Вы просто получаете это бесплатно.
И, наконец, к вопросу тестирования. Когда вы тестируете что-то, если в нем есть жестко запрограммированное новое, вы не можете легко заменить его на смоделированный объект для подачи тестовых данных. Предположим, вы хотите проверить, правильно ли объект вычисляет значение. Наполнение тестовых данных известными значениями облегчает тестирование.
Основным преимуществом инверсии управления является развязка. Развязывая, вы улучшаете ремонтопригодность. Ваш контроллер / действие зависит от интерфейса, и реализация вводится в контроллер.
Разрешение зависимостей через контейнер IoC упрощает логику внедрения зависимостей для вашего контроллера путем настройки контейнера. На самом деле становится ясно, что если один класс зависит от сервиса, этот сервис зависит от других сервисов, и эти сервисы также могут зависеть от большего количества сервисов, контейнер будет обрабатывать это разрешение зависимостей.
Многие люди могут посоветовать вам реализовать инверсию управления, чтобы иметь возможность тестировать ваш код, это не то, что предлагает инверсия управления, это делает ваш код более тестируемым, но это не главная причина.