Kozmic のブログ (2009 年付け) で、コンテナからオブジェクトを取得するためにジェネリック ファクトリを推奨しています。これは疑似サービス ロケーターのように思えます。そこで専門家の意見をお聞きしたいです。
public interface IGenericFactory
{
T Create<T>();
}
これを使用して Windsor コンテナからオブジェクトを取得できますか? このアプローチに欠点はありますか?
アップデート：
実際には、複数のファクトリを作成したくないいくつかのトランジェントのみを取得するために使用したいと考えています。そのようなすべてのシナリオに対して 1 つの工場を持つこと。
代わりに、次のことを考慮してください。
public interface IGenericFactory<out T>
{
T Create();
}
インターフェイスは 1 回だけ作成する必要がありますが、解決する必要があるサービスごとに挿入する必要があります。このように、これは一般的なサービス ロケーターではありません (前述の w0lf で言及されているように、これはアンチパターンです)。
ボーナスポイント：
通常の依存性注入では、依存性グラフ内のすべてのサービスを解決できる必要があります。 IGenericFactory<>型付けされたファクトリ機能を介して自動的に解決されます。ただし、そのジェネリック型引数は、実行するまで解決されませんCreate()。
プログラムの深いところにあるエッジ ケースでそれが発生し、サービスを登録するのを忘れた場合、本番になるまでバグに気付かない可能性があります。
IGenericFactory<>解決策は、ジェネリック型引数にハンドラーがあるかどうか、依存関係が登録されるのを待っていないかどうかをチェックするカスタム リゾルバーを作成することです。カスタム リゾルバーに関する情報はこちら: http://docs.castleproject.org/Windsor.Resolvers.ash
Google で簡単に検索したところ、おそらくあなたが参照していると思われるこの記事を見つけました: http://kozmic.pl/2009/12/23/castle-typed-factory-facility-reborn/
その場合、Krzysztof Koźmic は次のように述べています。
[...] 文字通り手間をかけずに、それを使用して汎用サービス ロケータを構築できます。
はい、現在Service Locator はアンチパターンと見なされています。
ただし、この記事は例外的なケースに関するものです。著者は、最初の段落でそれを非常に明確に述べています。
IoC コンテナーを使用する際の一般的な経験則は、コンポーネント (ブートストラップ コードの外部の任意の場所) でコンテナーを参照している場合、間違っていることです。すべてのルールと同様に例外がありますが、まれです。