Почему MVC4 использует Anti-Pattern Service Locator?

Question

После прочтения «Внедрения зависимостей в .NET» Марка Симанна я остаюсь в стороне от Service Locator , который является анти-паттерном.

После прочтения замечаний к выпуску MVC 4 я вижу:

Улучшенная инверсия управления (IoC) через DependencyResolver: Web API теперь использует шаблон локатора службыреализованный средством разрешения зависимостей MVC для получения экземпляров для множества различных средств.

Таким образом, меня удивляет и вызывает недоумение, почему Microsoft использовала локатор служб в 2012 году.

Answer 1

Это деталь реализации, которая не должна вас волновать. Важно то, что теперь, когда веб-API использует DependencyResolver для разрешения зависимостей для множества различных средств, вы сможете использовать реальное внедрение зависимостей всякий раз, когда вы хотите подключиться к этим средствам. Так что в вашем коде вы будете использовать реальное внедрение зависимостей. Если Microsoft не использовала DependencyResolver, то именно вы должны были использовать его (как антишаблон поиска служб) в своем коде, чтобы разрешить зависимости, когда вы хотите реализовать некоторые пользовательские функции. Это было бы плохо для вас . Теперь это плохо для Microsoft , но вы не заботитесь о них.

Таким образом, я остаюсь любопытным и запутанным, почему Microsoft будет использовать локатор служб в 2012 году.

Потому что разработка фреймворка - это не то же самое, что разработка приложения с использованием фреймворка. При разработке многократно используемой среды, такой как ASP.NET MVC, следует принимать во внимание разные вещи, а не только то, что написано в книгах. Некоторым примером является разработка структуры таким образом, чтобы человек, использующий эту среду, смог воспользоваться преимуществами лучших практик, написанных в книгах, в своем коде, используя эту среду.

Answer 2

Как указывает Дарин, ASP.NET MVC 4 является платформой и не зависит от контейнера.Вот почему он предоставляет сервисный локатор в виде IDependencyResolver.Это позволяет любому подключить выбранный контейнер.

Однако я бы не назвал это анти-паттерном.Это позволяет вам использовать контейнер по вашему выбору, но не заставляет вас разработчика приложений использовать расположение службы.Если бы фреймворк заставлял разработчика использовать Service Location, я бы назвал это анти-паттерном.Но разработчик, который создает приложение ASP.NET MVC, может свободно использовать DI через внедрение конструктора, настройку свойства или расположение службы.Это их выбор.

Посмотрите на все примеры внедрения зависимостей в ASP.NET MVC, опубликованные мной или командой ASP.NET MVC.Практически во всех случаях они используют инжектор конструктора.Они не используют расположение службы.

Фактически, большая часть самого исходного кода ASP.NET MVC сама не использует расположение службы для получения зависимостей.Есть несколько ключевых мест, где MVC вызывает сервисный локатор для устаревших API и тому подобное.Но это все.