4

autofac で依存性注入を使用する ASP.NET MVC3 ソリューションに取り組んでいます。私たちのコントローラーは autofac によって適切に作成されており、必要なすべてのオブジェクトが適切に渡されています。これらのオブジェクトには通常、サービス、リポジトリ、およびドメイン オブジェクトを MVC (ビュー) モデルに変換するマッパーが含まれます。したがって、コントローラーのコンストラクターは次のようになります。

public abcController(
        ILogger logger,
        IabcRepository abcRepository,
        IabcService abcService,
        IMapper<AbcDomain, AbcViewModel> abcMapper,
        ...
        )

残念ながら、時間が経つにつれて、これらのコンストラクターのパラメーター リストは非常に急速に大きくなる傾向があります。一部のコントローラーは、現在 60 以上のパラメーターを想定しています。

ここでアンチパターンを作成しましたか?

編集

薄いコントローラーのパターンに従おうとしていることは言及しておくべきでした。また、これらのパラメータのほとんどはマッパーである傾向があり、約 66% です。通常、制御メソッドは非常に単純で、次のいずれかのパターンに従います。

  • パラメータに基づいて、適切なサービスまたはリポジトリを呼び出します
  • マッパーを使用して結果を適切なビュー モデルに変換する
  • ビューモデルをビューに渡す

またはこのパターン：

  • 投稿アクションからモデルを受け取る
  • マッパーを使用して、適切なドメイン オブジェクトに変換します
  • ドメイン オブジェクトを使用して適切なサービスまたはリポジトリを呼び出す
4

4 に答える 4

8

コントローラーをどのように再設計する必要があるかについては、実際には話せませんが、他のほとんどの回答には同意します.60個の着信パラメーターはたくさんあります.

依存関係の数ではなくパラメーターの数を減らすのに役立つ可能性があるのは、 Autofac が持つAggregate Service サポートです。

60 個のパラメーターを直接取得する代わりに、60 個のプロパティを持つ単一の集計パラメーターを取得できます。

依存関係を使用してインターフェイスを作成します (インターフェイスのみで、実際に実装する必要はありません)。

public interface IMyAggregateService
{
  IFirstService FirstService { get; }
  ISecondService SecondService { get; }
  IThirdService ThirdService { get; }
  IFourthService FourthService { get; }
}

次に、コントローラーを変更して、その集約インターフェイスを取得します。

public class SomeController
{
  private readonly IMyAggregateService _aggregateService;

  public SomeController(
    IMyAggregateService aggregateService)
  {
    _aggregateService = aggregateService;
  }
}

集約サービス インターフェイス、依存関係、およびコントローラーを登録できます。コントローラーを解決すると、集約サービス インターフェイスが自動的に実装され、解決されます。

var builder = new ContainerBuilder();
builder.RegisterAggregateService<IMyAggregateService>();
builder.Register(/*...*/).As<IFirstService>();
builder.Register(/*...*/).As<ISecondService>();
builder.Register(/*...*/).As<IThirdService>();
builder.Register(/*...*/).As<IFourthService>();
builder.RegisterType<SomeController>();
var container = builder.Build();

繰り返しになりますが、多くの依存関係を必要とするというより大きな問題については触れていませんが、コンストラクターとコントローラーのプロパティの数を単純化して管理しやすくしたいだけの場合、これは Autofac が提供する 1 つの戦略です。 .

詳細については、wiki ページを参照してください。

于 2013-01-25T16:01:07.973 に答える
6

60以上のパラメータがたくさんあります。

あなたの質問では、「これらのオブジェクトには通常、ドメインオブジェクトをMVC（ビュー）モデルに変換するサービス、リポジトリ、マッパーが含まれます...」と述べました。

Fat Controller（Thomas The Task Engineの種類ではありません）がありますが、あまりにも多くのことをしているコントローラーがあります。

私が探しているバランスは、ファットモデルスキニーコントローラーです。IanCooperはこのブログ投稿でそれについてよく話します

また、どのパラメーターが実際に分野横断的な懸念事項であるかなどを確認することもできます。

たとえば、私の頭の中のマッピングとロギングは横断的関心事であるため、アクションフィルターを使用してコントローラーをクリーンアップできる可能性があります。

于 2013-01-24T22:29:34.240 に答える
3

（免責事項：この回答は、引数リストのサイズに関するものでした。コントローラー内の依存関係を減らすものではありません）

この場合、Factory を注入します。

例えば：

interface IABCFactory {
    ILogger CreateLogger();
    IABCRepository CreateRepo();
    // .. etc
}

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

private ILogger _logger;

public abcController(IABCFactory factory) {
    _logger = factory.CreateLogger();
    // .. etc
}

パブリックプロパティに注入できることに注意してください..しかし、それを外部の世界に公開するかどうかはあなた次第です。カプセル化を壊したくない場合は、ファクトリを使用します。

于 2013-01-24T22:18:13.990 に答える