Почему MVC4 использует Anti-Pattern Service Locator?
После прочтения "Внедрения зависимостей в.NET" Марка Симанна я остался в стороне от Сервисного локатора, который является анти-паттерном.
После прочтения примечаний к выпуску MVC 4 я вижу:
Улучшенная инверсия управления (IoC) с помощью DependencyResolver: теперь веб-API использует шаблон локатора служб, реализованный средством разрешения зависимостей MVC, для получения экземпляров для множества различных средств.
Таким образом, я остаюсь любопытным и запутанным, почему Microsoft будет использовать сервисный локатор в 2012 году.
2 ответа
Это деталь реализации, которая не должна вас волновать. Важно то, что теперь, когда веб-API использует DependencyResolver для разрешения зависимостей для множества различных средств, вы сможете использовать реальное внедрение зависимостей всякий раз, когда вы хотите подключиться к этим средствам. Так что в вашем коде вы будете использовать реальное внедрение зависимостей. Если Microsoft не использовала DependencyResolver тогда именно вы, должно быть, использовали его (как антишаблон поиска служб) в своем коде для разрешения зависимостей, когда вы хотите реализовать некоторые пользовательские функции. Это было бы плохо для вас. Теперь это плохо для Microsoft, но вы не заботитесь о них.
Таким образом, я остаюсь любопытным и запутанным, почему Microsoft будет использовать сервисный локатор в 2012 году
Потому что разработка фреймворка - это не то же самое, что разработка приложения с использованием фреймворка. При разработке многократно используемой среды, такой как ASP.NET MVC, необходимо учитывать несколько разных моментов, а не только то, что написано в книгах. Некоторый пример - спроектировать фреймворк таким образом, чтобы человек, использующий этот фреймворк, мог воспользоваться преимуществами лучших практик, написанных в книгах в своем коде, используя этот фреймворк.
Как указывает Дарин, ASP.NET MVC 4 является платформой и не зависит от контейнера. Вот почему он предоставляет сервисный локатор в виде IDependencyResolver, Это позволяет любому подключить свой контейнер по выбору.
Однако я бы не назвал это анти-паттерном. Это позволяет вам использовать контейнер по вашему выбору, но не заставляет разработчика приложения использовать местоположение службы. Если бы фреймворк заставлял разработчика использовать Service Location, я бы назвал это анти-паттерном. Но разработчик, который создает приложение ASP.NET MVC, может свободно использовать DI через внедрение конструктора, настройку свойства или расположение службы. Это их выбор.
Посмотрите на все примеры внедрения зависимостей в ASP.NET MVC, опубликованные мной или командой ASP.NET MVC. В большинстве случаев они используют инжекцию конструктора. Они не используют сервисное местоположение.
Фактически, большая часть исходного кода ASP.NET MVC сама по себе не использует расположение службы для получения зависимостей. Есть несколько ключевых мест, где MVC вызывает сервисный локатор для устаревших API и тому подобное. Но это все.