MVC4がServiceLocator Anti-Patternを使用しているのはなぜですか？
"Dependency Injection in .NET" by Mark Seemannを読んだ後、アンチパターンである Service Locator には近づきません。
読んだとき MVC 4のリリースノート わかりました：
DependencyResolverによる制御の反転（IoC）の改善：Web APIは、MVCの依存関係リゾルバーによって実装されたサービスロケーターパターンを使用して、さまざまな機能のインスタンスを取得するようになりました。
したがって、マイクロソフトが2012年にサービスロケーターを使用する理由に興味があり、混乱しています。
これは、気にする必要のない実装の詳細です。重要なことは、Web APIがDependencyResolverを使用して多くの異なる機能の依存関係を解決するようになったため、これらの機能にプラグインするときはいつでも実際の依存性注入を使用できるようになることです。したがって、コードでは、実際の依存性注入を使用します。 MicrosoftがDependencyResolverを使用しなかった場合、カスタム機能を実装するときに依存関係を解決するために、コードで（サービスロケーターのアンチパターンとして）それを使用する必要があります。これはあなたにとって悪いだったでしょう。今ではMicrosoftにとっては悪いですが、気にしません。
したがって、マイクロソフトが2012年にサービスロケーターを使用する理由に興味があり、混乱しています。
フレームワークの設計は、フレームワークを使用したアプリケーションの設計と同じではないためです。本に書かれていることだけでなく、ASP.NETMVCなどの再利用可能なフレームワークを設計する際に考慮すべきいくつかの異なることがあります。いくつかの例は、このフレームワークを使用する人が、このフレームワークを使用して自分のコードの本に書かれているベストプラクティスを利用できるようにフレームワークを設計することです。
Darinが指摘しているように、ASP.NET MVC 4はフレームワークであり、コンテナーに依存しません。そのため、IDependencyResolverの形式でサービスロケーターを提供します。これにより、誰でも選択したコンテナを接続できます。
ただし、これをアンチパターンとは呼びません。これにより、選択したコンテナーを使用できますが、 you アプリケーション開発者にサービスの場所の使用を強制することはありません。フレームワークが開発者にServiceLocationの使用を強制した場合、私はそれをアンチパターンと呼びます。ただし、ASP.NET MVCアプリケーションを構築する開発者は、コンストラクターの挿入、プロパティのセットアップ、またはサービスの場所を介してDIを自由に使用できます。それは彼らの選択です。
私またはASP.NETMVCチームによって公開された依存性注入のすべてのASP.NETMVCの例を見てください。ほとんどすべての場合、コンストラクターインジェクションを使用しています。彼らはサービスの場所を使用していません。
実際、ほとんどのASP.NET MVCソースコード自体は、依存関係を取得するためにサービスの場所を使用しません。 MVCがレガシーAPIなどのサービスロケーターを呼び出す重要な場所がいくつかあります。しかし、それはそれについてです。