それらは同じものですか？Rob ConneryのStorefrontチュートリアルの視聴を終えたばかりで、それらは同様のテクニックのようです。つまり、DALオブジェクトを実装するときは、GetStuff、Add / Deleteなどのメソッドを使用し、後でdbを切り替えられるように、常に最初にインターフェイスを記述します。
混乱しますか？
それらは同じものですか？Rob ConneryのStorefrontチュートリアルの視聴を終えたばかりで、それらは同様のテクニックのようです。つまり、DALオブジェクトを実装するときは、GetStuff、Add / Deleteなどのメソッドを使用し、後でdbを切り替えられるように、常に最初にインターフェイスを記述します。
混乱しますか？
回答:
あなたは間違いなく物事を混乱させる人ではありません。:-)
質問への答えは、どれだけ純粋主義者になりたいかにかかっていると思います。
厳密なDDDの視点が必要な場合は、1つのパスをたどります。リポジトリを、サービスとデータベースを分離するレイヤーのインターフェースを標準化するのに役立つパターンと見なすと、別のレイヤーに移動します。
私の観点から見たリポジトリは、データへのアクセスの明確に指定されたレイヤーにすぎません。つまり、データアクセスレイヤーを実装するための標準化された方法です。リポジトリの実装にはいくつかの違いがありますが、概念は同じです。
リポジトリにさらにDDD制約を課す人もいれば、データベースとサービス層の間の便利なメディエーターとしてリポジトリを使用する人もいます。DALのようなリポジトリは、サービスレイヤーをデータアクセスの詳細から分離します。
それらを異なるように見せている実装上の問題の1つは、仕様をとるメソッドを使用してリポジトリが作成されることが多いことです。リポジトリは、その仕様を満たすデータを返します。私が見てきたほとんどの従来のDALには、メソッドが任意の数のパラメーターを取る、より大きなメソッドセットがあります。これは小さな違いのように聞こえるかもしれませんが、Linqと式の領域を入力するとき、それは大きな問題です。デフォルトのリポジトリインターフェースは次のようになります。
public interface IRepository : IDisposable
{
T[] GetAll<T>();
T[] GetAll<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors);
void Delete<T>(T entity);
void Add<T>(T entity);
int SaveChanges();
DbTransaction BeginTransaction();
}これはDALまたはリポジトリですか？この場合、私はその両方を推測します。
キム
リポジトリはさまざまな方法で適用できるパターンですが、データアクセスレイヤーには非常に明確な責任があります。DALはデータストレージに接続してCRUD操作を実行する方法を知っている必要があります。
リポジトリは DALにすることもできますが、DALの前に配置して、ビジネスオブジェクトレイヤーとデータレイヤーの間のブリッジとして機能させることもできます。使用される実装はプロジェクトごとに異なります。
1つの大きな違いは、DAOはドメイン内のエンティティの永続性を処理する一般的な方法であることです。一方、リポジトリは集約ルートのみを扱います。
私は同様の質問への回答を探していて、2つの最高ランクの回答に同意しました。自分のためにこれを明確にしようとすると、私が発見した場合は、リポジトリパターンと手に手を行く仕様は、ドメインモデルのファーストクラスのメンバーとして実装され、その後、私ができます
私はこれまでのところ、Repositoryパターンが仕様パターンと一緒に使用されない限り、それは実際には「リポジトリ」ではなくDALであると述べているかもしれません。疑似コードの不自然な例：
specification100 = new AccountHasMoreOrdersThan(100)
specification200 = new AccountHasMoreOrdersThan(200)
assert that specification200.isSpecialCaseOf(specification100)
specificationAge = new AccountIsOlderThan('2000-01-01')
combinedSpec = new CompositeSpecification(
SpecificationOperator.And, specification200, specificationAge)
for each account in Repository<Account>.GetAllSatisfying(combinedSpec)
assert that account.Created < '2000-01-01'
assert that account.Orders.Count > 200詳細については、Fowler's Specification Essayを参照してください（これは、上記に基づいています）。
DALには、次のような特殊なメソッドがあります。
IoCManager.InstanceFor<IAccountDAO>()
.GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')特に、この方法で各DAL / DAOインターフェイスを定義し、DALクエリメソッドを実装する必要があるため、これがいかに面倒になるかを理解できます。
.NETでは、LINQクエリは仕様を実装する1つの方法ですが、仕様（式）の組み合わせは、自社開発のソリューションほどスムーズではない場合があります。そのためのいくつかのアイデアは、このSO質問で説明されています。
私の個人的な意見では、それはすべてマッピングに関するものであると考えています。http：//www.martinfowler.com/eaaCatalog/repository.htmlを参照してください。したがって、リポジトリからの出力/入力はドメインオブジェクトであり、DALでは何でもかまいません。私にとって、これは重要な追加/制限です。異なるレイアウトでデータベース/サービス/リポジトリの実装を追加でき、マッピングを行うことに集中できる明確な場所があるからです。その制限を使用せず、他の場所にマッピングがある場合は、データを表す別の方法を使用すると、変更してはならない場所のコードに影響を与える可能性があります。
では、（単純な）ほとんどの場合、DAOはリポジトリの実装ですか？
私が理解している限り、DAOはdbアクセス（CRUD-選択なし？！）を正確に処理しているようですが、リポジトリではデータアクセス全体を抽象化できます。
私は正しい道を進んでいますか？
外界（つまり、クライアントコード）のリポジトリは、以下を除いてDALと同じです。
（1）挿入/更新/削除メソッドは、データコンテナーオブジェクトをパラメーターとして持つように制限されています。
（2）読み取り操作の場合、DAL（たとえば、GetByPK）のような単純な仕様または高度な仕様をとることがあります。
内部的には、データマッパーレイヤー（エンティティフレームワークコンテキストなど）と連携して、実際のCRUD操作を実行します。
リポジトリパターンが意味しないもの：-
また、挿入/更新/削除メソッドによって実行されるすべてのメモリ内の変更をデータベースにコミットする挿入/更新/削除メソッドの他に、リポジトリパターンのサンプル実装として、別のSaveメソッドがあると混乱することがよくあります。リポジトリにSaveメソッドを確実に含めることができますが、インメモリCUD（作成、更新、削除）と永続化メソッド（データベースで実際の書き込み/変更操作を実行）を分離することはリポジトリの責任ではありませんが、作業単位パターンの責任。
お役に立てれば！