0

ここには、NHibernateの世界からの「SELECTN+1」に非常によく似た状況があります。

アプリケーションASP.NETMVCアプリを作成していますが、HomeControllerにはIUserSignUpServiceが必要です。IUserSignUpServiceは、具象クラスUserSignUpServiceにバインドされているアプリケーションサービスレイヤーに「存在」します。

UserSignUpServiceには2つの依存関係があります。

public IUserRepository UserRepository { get; set; }
public Domain.Services.IUserSignUpService SignUpService { get; set; }

public UserSignUpService(IUserRepository userRepository, Domain.Services.IUserSignUpService signUpService)
{
    this.UserRepository = userRepository;
    this.SignUpService = signUpService;
}

Autofacがアプリケーションサービスレイヤーに存在するIUserSignUpServiceを解決する場合、永続レイヤーに存在するIUserRepository依存関係と、内部に存在するDomain.Services.IUserSignUpService（同じ名前ですが異なる）を解決する必要があります。ドメインを作成し、データベースに対してINSERTSQLを実行する前にいくつかのアクションを実行します。

IUserRepositoryインターフェースは、コンストラクターを介して注入されるISessionインスタンスを必要とするUserRepositoryクラスによって実装されます。

ここでの私のポイントは：

このアプローチを使い続けると、HomeControllerへのHttpRequestを受け取るたびに、新しいISessionを開始します（これは、HomeControllerのコンストラクター依存関係であるIUserSignUpControllerへのコンストラクター依存関係であるUserRepositoryのコンストラクター依存関係であるため） 。

毎回すべてが必要というわけではありません。現在のLifeTimeScopeにIUnitOfWorkインターフェイスのインスタンスがある場合にのみ、ISessionを解決するようにAutofacに指示できるかもしれません。

出来ますか？

4

1 に答える 1

2

ISessionを構築しないために余分な作業を行うことが時期尚早の最適化であるかどうかをテストします。重要なパフォーマンスヒットはありますか？

その場合、「毎回必要ではない」コンストラクターの依存関係をLazy <>でラップすると、Autofacはインスタンス化を遅らせます。

于 2012-06-27T03:05:14.880 に答える