Mark Seemannの「Dependency Injection in .NET」を読んだ後、アンチパターンであるService Locatorには近づきません。
MVC 4 のリリース ノートを読むと、次のように表示されます。
DependencyResolver による制御の反転 (IoC) の改善: Web API は、MVC の依存関係リゾルバーによって実装されたサービス ロケーター パターンを使用して、さまざまな機能のインスタンスを取得するようになりました。
したがって、Microsoft が 2012 年にサービス ロケーターを使用する理由について、私は好奇心と混乱を覚えています。
これは、気にする必要のない実装の詳細です。重要なことは、Web API が DependencyResolver を使用してさまざまな機能の依存関係を解決するようになったため、それらの機能にプラグインするときはいつでも実際の依存関係の注入を使用できるようになることです。したがって、コードでは、実際の依存性注入を使用します。Microsoft が を使用しなかった場合、DependencyResolverカスタム機能を実装するときに依存関係を解決するために、コードで (サービス ロケーターのアンチパターンとして) 使用したに違いないのはあなたでした。これはあなたにとって悪いことでした。Microsoftにとっては悪いことですが、あなたはそれらを気にしません.
したがって、Microsoft が 2012 年にサービス ロケーターを使用する理由について、私は好奇心と混乱を覚えています。
フレームワークを設計することは、フレームワークを使用してアプリケーションを設計することと同じではないためです。ASP.NET MVC などの再利用可能なフレームワークを設計する際には、本に書かれていることだけではなく、考慮すべき点がいくつかあります。いくつかの例は、このフレームワークを使用する人が、このフレームワークを使用するコードで本に書かれているベスト プラクティスを利用できるようにフレームワークを設計することです。
Darin が指摘するように、ASP.NET MVC 4 はフレームワークであり、コンテナーに依存しません。そのため、サービスロケーターをIDependencyResolver. これにより、誰でも選択したコンテナーをプラグインできます。
ただし、これをアンチパターンとは呼びません。これにより、選択したコンテナーを使用できますが、アプリケーション開発者がサービスの場所を使用する必要はありません。フレームワークが開発者に Service Location の使用を強制する場合、私はそれをアンチパターンと呼びます。ただし、ASP.NET MVC アプリケーションを構築する開発者は、コンストラクターの挿入、プロパティのセットアップ、またはサービスの場所を介して自由に DI を使用できます。それは彼らの選択です。
私または ASP.NET MVC チームが公開した依存性注入の ASP.NET MVC の例をすべて見てください。ほとんどの場合、コンストラクター インジェクションを使用しています。彼らはサービスの場所を使用していません。
実際、ASP.NET MVC ソース コード自体のほとんどは、サービスの場所を使用して依存関係を取得していません。MVC がレガシー API などのサービス ロケーターを呼び出す重要な場所がいくつかあります。しかし、それはそれについてです。