0

ランタイム パラメーターと暗黙的なコンストラクション インジェクションが混在していることにますます気付き、悪臭を放っています。

例 - フィルターを記述する基本クラスと、特定のフィルターのさまざまな継承タイプ (タグ、カテゴリ、日付、作成者など) があります。

var filter = StructureMap.ObjectFactory
.With("caption").EqualTo("Posts filtered by tag:")
.With("parameters").EqualTo(parameters)
.With("displayInSummary").EqualTo(true)
.GetInstance<TagListFilter>();

これを行う理由は、コンストラクターに、StructureMap に具象クラス (IArticleConfigurator) を挿入するために使用するインターフェイスがあるためです。

public TagListFilter(string caption, IDictionary<string,string> parameters, bool displayInSummary, IArticleConfigurator configurator)
:base(caption, parameters,displayInSummary, configurator)

しかし、単純なコンストラクターを、インターフェイスではなく具象クラスに置き換えましたが、基本的には同じものに置き換えましたが、DIを使用して1つの具象型を注入しました。現在、私たちの構成はxmlファイルにありますが、CMSに移動されるため、これを行っているため、インターフェイスを使用することをお勧めします。

それは間違っているようで、DIの精神ではありません。

ファクトリを使用してさまざまなフィルターを生成する必要がありますか? その場合、DI を利用して IArticleConfigurator の具体的なインスタンスを取得できますか?

4

1 に答える 1

1

ある依存関係から別の依存関係にパラメーターを明示的に渡すべきではありません。少なくとも、その数を最小限に抑える必要があります。パラメーターを使用してインスタンスを解決することの大きな欠点の 1 つは、パラメーター名を文字列リテラルとして指定することです。これにより、コンストラクター シグネチャの変更時にコードが非常に壊れやすくなります。

私が考えるかもしれない1つの例（あなたのドメインとエンティティの責任について私は手がかりがないことに注意してください）は、プロバイダーまたはすでに述べたように、ファクトリーを注入することです。たとえば、ITagListFilterConfigurationProvider（名前は好きなように変更してください。モチベーションを上げようとしているだけです）のようなものを作成します。IFilterConfigurationProviderフィルターに同じパラメーターがある場合、以下の 3 つのメソッドを使用して、非常に抽象的なプロバイダーを作成できます。

interface ITagListFilterConfigurationProvider
{
    string Caption { get; }
    IDictionary<string,string> GetParameters();
    bool IsDisplayInSummary { get; }
}

コンストラクタは次のようになります。

public TagListFilter(ITagListFilterConfigurationProvider configurationProvider, IArticleConfigurator configurator)

必要なのは、既に行ったように実装し (具体的なパラメーターをコンストラクターに渡すため)、この動作をプロバイダーに抽出することだけです。残っているのは、具体的なプロバイダーを StructureMap に登録し、具体的なパラメーターを渡さずにフィルターを解決することです。

var filter = StructureMap.ObjectFactory.GetInstance<TagListFilter>();
于 2013-01-16T09:17:48.217 に答える