2

より良いテストを可能にするために、エンティティ フレームワークとリポジトリをさらに深く掘り下げます。これが賢明かどうか疑問に思いますか？ 

public interface IRepository
{
    int SaveChanges();

    void Dispose();
}

using (MyContext context = new MyContext())
{
    TransactionRepository txns = new TransactionRepository(context); // TransactionRepository implement IRepository
    MappingRepository maps = new MappingRepository(context); // MappingRepositoryimplement IRepository

    SomeCommand command = new SomeCommand(txns, maps);
    command.Execute();
}

各リポジトリは論理的に異なるため、理論的には異なるデータ ソースにある可能性があります。ただし、今のところ、同じデータベースを使用しています。各リポジトリ クラスは IRepository を実装しており、特に SaveChanges() と、簡潔にするために示していないいくつかのクエリ メソッドが実装されています。

複数のリポジトリを利用するための良い方法は何ですか?

4

3 に答える 3

4

+1ゴリラ、いくつかの商品ポイントが作られました。以下の考えを追加します。

web/mvc シナリオでは、数十のリポジトリを使用し、これらのリポジトリにコンテキストを挿入します。リポジトリ基本クラスを使用します。コンストラクターでコンテキストを使用する UoW クラスもあります。Unit Of Work クラスには、コンテキストでサポートされているすべてのリポジトリへの参照が含まれています。また、境界付けられたコンテキストも使用します。これは、この件に関する Julie Lerman のサンプル ブログです。 http://www.goodreads.com/author/show/1892325.Julia_Lerman/blog

そうです、複数のコンテキストを使用し、複数のリポジトリを使用することは完全に理にかなっています。複数の Unit of Work クラスを使用することもできますが、UoW クラスの同時使用については別の議論です。

ADDING SAMPLE code as requested: このサンプルは、ベース LuW クラスから継承するいくつかの LuW クラスの 1 つです。現在の状態と使用する DBContext が注入されます。(またはデフォルト) リポジトリは、CORE プロジェクトからのインターフェイスです。LuW クラスは DAL プロジェクトにあります。

ベースLuWは....のようなものです

public interface ILuw : ILuwEvent, IDisposable
  {

   IBosCurrentState CurrentState{ get; set; }
   OperationStatus Commit();

   }

ルウ級そのもの。

namespace XYZ.DAL
{
public class LuwBosMaster : Luw, ILuwBosMaster
{
    public LuwBosMaster(DbContext context, IBosCurrentState currentState)  
    {
       base.Initialise(context,currentState); 
    }
    public LuwBosMaster()
    {

        base.Initialise(GetDefaultContext(), BosGlobal.BGA.IBosCurrentState);
    }
    public static DbContextBosMaster GetDefaultContext()
    {
     return new DbContextBosMaster("BosMaster");
    }

    //MasterUser with own Repository Class
    private IRepositoryMasterUser _repositoryMasterUser;
    public  IRepositoryMasterUser RepMasterUser
    { get { return _repositoryMasterUser ?? (_repositoryMasterUser = new RepositoryMasterUser(Context, CurrentState)); } }

    //20 other repositories declared adn available within this Luw
    // Some repositories might address several tables other single tables only.
    //  The repositories are based on a base class that common generic behavior for each MODEL object

基本的な考え方は理解できると思います...

于 2013-01-31T00:36:29.070 に答える
3

これは本当にあなたの側の設計上の決定に帰着します。作業単位のパターンに従っている場合、各リポジトリにはおそらく独自のコンテキストがあります。主な理由は、UoWによると、各リポジトリ呼び出しはそのコンテキストを作成し、それを機能させてから、そのコンテキストを破棄する必要があるためです。

ただし、コンテキストを共有する理由は他にもありますが、その1つ（IMHO）は、コンテキストがエンティティの状態を追跡する必要があることです。エンティティを取得した場合は、コンテキストを破棄し、エンティティにいくつかの変更を加えます。次に、新しいコンテキストにアタッチします。この新しいコンテキストは、エンティティの状態を把握できるようにデータベースにアクセスする必要があります。同様に、エンティティ（InvoicesとそのすべてのInvoiceItems）のグラフを操作している場合、新しいコンテキストは、グラフ内のすべてのエンティティをフェッチして、それらの状態を判別する必要があります。

現在、状態を維持していない、または維持できないWebページまたはサービスを使用している場合、UoWパターンは一種の暗黙の意味であり、一般的に受け入れられている「グッドプラクティス」です。

于 2013-01-31T00:16:23.883 に答える
1

最も重要なことは忘れられています: データベース接続は複数のDbContextインスタンス間で共有されません。つまり、複数のリポジトリを同じトランザクションに含める場合は、分散トランザクションを使用する必要があります。これは、ローカル トランザクションに比べて大幅なパフォーマンスの低下です。

于 2013-02-05T06:32:26.807 に答える