Почему использование модели провайдера в новом приложении ASP.Net MVC выглядит задом наперед?

Question

Недавно я перешел от команды, использующей Ninject в ASP.Net MVC для внедрения зависимостей, к команде, которая ничего не знает о решениях IoC, кроме шаблона модели провайдера, который был представлен в ASP.Net 2.0.

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

Теперь я начинаю небольшой проект ASP.Net MVC по разработке новых технологий и нахожу сопротивление со стороны некоторых членов команды принятию структуры DI.

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

Может кто-нибудь описать объективные различия между двумя подходамии почему писать против модели провайдера в среде, где контейнер может быть легко загружен, кажется странным?

Answer 1

Идиома провайдера - в лучшем случае дизайнерский запах .Лучше всего избегать этого полностью.

Внедрение зависимостей, с другой стороны, просто самый эффективный способ обеспечения слабой связи .Если вы хотите написать обслуживаемый код , это один из наиболее эффективных способов достижения этой цели.

Однако большинство людей склонны сопротивляться DI, потому что это «чувствует» назад, но это действительночто-то, что нужно преодолеть.

Answer 2

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

Допустим, у вас есть приложение, которое вызывает некоторые внешние сторонние сервисы, но также имеет локальную базу данных. Ваши контроллеры иногда вызывают «провайдера» (для внешних служб), но иногда вызывают «репозиторий» для локальной базы данных. Итак, как вы собираетесь провести модульное тестирование методов, которые вызывают хранилище? Я предполагаю, что вам нужно абстрагировать всю вашу локальную базу данных через провайдеров. В этом случае вы либо получите одну или две огромные реализации провайдера (плохой дизайн, чтобы иметь слишком много методов на класс), либо вы получите множество мелких провайдеров (кошмар конфигурации).

С контейнером IOC вы можете выполнить большую часть соединений в самом коде. Использование насмешливого фреймворка облегчает юнит-тестирование. Поэтому, если вы действительно хотите, вы можете использовать провайдеров для «внешних вызовов» и IOC для «внутренних вызовов».

Я просто размышляю над этим, потому что у нас много унаследованного кода в провайдерах, и я думаю отойти от них и просто использовать прямой IOC. Я полагаю, что контейнеры IOC, такие как AutoFac, могут повторять это требование возможности «подключить» другую реализацию через конфигурацию, так что вы ничего не потеряете.

Узнайте больше на моем блоге - надеюсь, блог тоже получит хорошие комментарии: http://healthedev.blogspot.com/2011/12/making-custom-built-applications.html