7

これに関連する質問がいくつかありますが、探している答えがまだ見つからないので、質問を投稿しています。別の質問が答えを保持している場合（そして私はそれを見ていないだけです）、私にそれを指摘してください。

リポジトリパターンでEF4とUnityを使用しているときに、UnitOfWorkがどこに属しているか（具体的には作成されているか）を把握しようとしています。

基本的に、ビジネスロジックを実装するために使用されるサービスがあります。このサービスコンストラクターはリポジトリーを取り込むため、サービスは私のリポジトリーに注入されます。次に、サービスは挿入されたリポジトリを使用してデータストアに対してアクションを実行しますが、これらを作業単位でラップする必要があります。

ただし、私の作業単位には、EF4コンテキスト（または、私の場合は、コンテキストのインターフェイスであるIObjectContext）を注入する必要があります。そして、UoWをどこで作成し、コンテキストとともに挿入する必要があるのか​​わかりません。

これが私が考えることができる可能なオプションですが、どれも理想的ではないようです：

  • UoWをサービスコンストラクターに含めます。これにより、サービスが作業単位で注入され、作業単位がEF4コンテキストで注入されます。しかし、リポジトリのすべてのインスタンスでUoWを作成したくないので、これは間違っているようです。

  • container.Resolveを使用してオンデマンドで作成し、EF4コンテキストを挿入してUoWのインスタンスを取得します。これは、すでにUoWにアクセスできるのではなく、常にIoCコンテナにアクセスしなければならないという過剰なようです。

  • コンテキストをサービスに直接注入して、UoW（コンテキスト）を作成できるようにします。コンテキストをサービスに公開したので、これは悪いようです。これはリポジトリに分離する必要があります。

だから私の質問は、これらの方法の1つは受け入れられるのか、それとも私が考えていない別の方法があるのか​​ということです。

前もって感謝します。

4

2 に答える 2

12

これを使用する方法はおそらくいくつかあるので、私が有用だと思った方法を説明します。

UoWを定義する場所は、アプリケーションロジック（ビジネスレイヤー（ビジネスサービス）を呼び出すロジック）にあります。この理由は、UoWが論理的なビジネストランザクションを表す必要があるためです。アプリケーションロジック（またはリモート呼び出しの場合はサービスファサード）が論理トランザクションとは何かを定義します。したがって、たとえばMVCでは、各コントローラーアクションが単一のUoWを表すアーキテクチャを使用できます。

public class MyController : Controller
{
  public MyController(IFirstService firstService, ISecondService secondService,
    IUnitOfWork unitOfWork)
  { ... }

  [HttpPost]
  public ActionResult SomeAction(Model data)
  {
    _firstService.SomeProcessing(data);
    _secondService.SomeProcessing(data);
    _unitOfWork.SaveChanges();
    return RedirectToAction(...);
  }
}

この例では、私のコントローラーは2つのビジネスサービスに依存しており、アクションはそれらを両方とも呼び出します。UoWは、両方のサービスによって実行された変更を保存します。アプリケーション層がUoWにアクセスできない場合、複数のサービス呼び出しからロジックを作成（再利用）できないため、コントローラーでUoWを使用できるようにする必要があるのはこのためです（それぞれが独自のSaveChangesを呼び出す可能性があるため）。

他のアプローチは、サービスファサードを使用することです。ファサードはビジネスレイヤーのパブリックインターフェイスになり、サービス構成を非表示にします。

_firstService.SomeProcessing(data);
_secondService.SomeProcessing(data);
_unitOfWork.SaveChanges();

このような場合、UoWはコントローラーに渡されませんが、サービスファサードに渡され、サービスファサードがコントローラーに注入されます。ビジネスロジックがWebサービス（または他のリモートテクノロジ）を介して公開される場合は、このアプローチを確実に使用します。

あなたが対処しなければならない最後の問題は、UoWをサービスに渡すことです。UoWだけでなくサービスもコントローラー（プレゼンター、サービスファサードなど）に注入されますが、同時にUoW（またはObjectContext）をサービスに注入して、内部で使用されるリポジトリーを操作できるようにする必要があります。このためには、同じ「リクエスト」内のすべてのインジェクションに対して同じインスタンスを返すように、正しいIoCライフタイムマネージャーが必要です。Webアプリケーションの場合、PerHttpRequestライフタイムマネージャーが必要です（Unityでは提供されていないため、自分で実装する必要があります）。

于 2011-02-17T09:00:43.623 に答える
1

これを管理する1つの方法は、http：//mfelicio.wordpress.com/2010/02/07/managing-the-entity-framework-objectcontext-instance-lifetime-in-wcf-and-sharingで説明されている方法を使用することです。 -it-among-repositories /この記事では、Wcfサービス用のContextManagerを実装しています。ASP.NETアプリの場合、次のようなものを使用できます。

public class AspNetDBContextManager<TContext> : IDBContextManager
    where TContext : IDBContext, new()
{
    #region IDBContextManager Members

    public IDBContext GetDBContext()
    {
        return this.GetOrCreateDbContext();
    }

    private IDBContext GetOrCreateDbContext()
    {
        if (HttpContext.Current == null)
        {
            throw new InvalidOperationException("Can be used only within ASP.NET applications");
        }

        string dbContextKey = string.Format("__AspNetDBCM__{0}__", HttpContext.Current.GetHashCode());

        object dbContext = HttpContext.Current.Items[dbContextKey];

        if (dbContext == null)
        {
            dbContext = new TContext();

            if (dbContext != null)
            {
                HttpContext.Current.Items[dbContextKey] = dbContext;
            }
        }

        return dbContext as IDBContext;
    }

    #endregion
}

public interface IDBContext
{
    object Context { get; }
}


public interface IDBContextManager
{
    IDBContext GetDBContext();
}
于 2011-02-17T18:31:09.850 に答える