asp.net-mvc - Repository Pattern vs DAL

Question

Are they the same thing? Just finished to watch Rob Connery's Storefront tutorial and they seem to be similar techinques. I mean, when I implement a DAL object I have the GetStuff, Add/Delete etc methods and I always write the interface first so that I can switch db later.

Am I confusing things?

score 89 · Accepted Answer

あなたは間違いなく物事を混乱させる人ではありません。:-)

質問に対する答えは、あなたがどれだけ純粋主義者になりたいかによると思います。

厳密な DDD の観点が必要な場合は、1 つの道をたどることになります。リポジトリを、サービスとデータベースを分離するレイヤーのインターフェイスを標準化するのに役立ったパターンと見なすと、別のことができなくなります。

私の観点から見ると、リポジトリはデータへのアクセスの明確に指定されたレイヤーです。つまり、データアクセスレイヤーを実装するための標準化された方法です。異なるリポジトリ実装にはいくつかの違いがありますが、概念は同じです。

リポジトリに DDD 制約を追加する人もいれば、データベースとサービス層の間の便利なメディエーターとしてリポジトリを使用する人もいます。DAL のようなリポジトリは、サービス層をデータアクセスの詳細から分離します。

それらを異なるものにしていると思われる実装上の問題の 1 つは、仕様を取るメソッドを使用してリポジトリが作成されることが多いことです。リポジトリは、その仕様を満たすデータを返します。私が見たほとんどの従来の DAL には、メソッドが任意の数のパラメーターを取る、より大きなメソッドのセットがあります。これは小さな違いのように聞こえるかもしれませんが、Linq と Expressions の領域に入ると大きな問題になります。デフォルトのリポジトリインターフェイスは次のようになります。

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 ですか、それともリポジトリですか? この場合、私はその両方を推測します。

キム

score 44 · Accepted Answer

リポジトリはさまざまな方法で適用できるパターンですが、データアクセスレイヤーには非常に明確な責任があります。つまり、DAL はデータストレージに接続して CRUD 操作を実行する方法を認識している必要があります。

リポジトリは DAL にすることもできますが、DAL の前に配置して、ビジネスオブジェクト層とデータ層の間のブリッジとして機能させることもできます。どの実装が使用されるかは、プロジェクトごとに異なります。

score 23 · Accepted Answer

大きな違いの1つは、DAOがドメイン内のエンティティの永続性を処理する一般的な方法であるということです。一方、リポジトリは集約ルートのみを扱います。

score 12 · Accepted Answer

同様の質問に対する回答を探していましたが、上位 2 つの回答に同意します。自分でこれを明確にしようとしたところ、リポジトリパターンと密接に関連する仕様がドメインモデルのファーストクラスメンバーとして実装されている場合、次のことができることがわかりました。

仕様定義を異なるパラメータで再利用します。
既存の仕様インスタンスのパラメーターを操作する (たとえば、特殊化するため)。
それらを組み合わせ、
データベースにアクセスすることなく、それらに対してビジネスロジックを実行します。
そしてもちろん、実際のリポジトリの実装とは別に単体テストを行います。

リポジトリパターンが仕様パターンと一緒に使用されない限り、それは実際には "リポジトリ" ではなく、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 では、仕様を実装する 1 つの方法として LINQ クエリを使用できますが、仕様 (式) を組み合わせることは、自家製のソリューションほどスムーズではない場合があります。そのためのいくつかのアイデアは、この SO Questionで説明されています。

score 2 · Accepted Answer

私の個人的な意見では、すべてはマッピングに関するものです。 http://www.martinfowler.com/eaaCatalog/repository.htmlを参照してください。したがって、リポジトリからの出力/入力はドメインオブジェクトであり、DAL では何でもかまいません。私にとって、これは重要な追加/制限です。データベース/サービス/さまざまなレイアウトのリポジトリ実装を追加でき、マッピングの実行に集中できる明確な場所があるからです。その制限を使用せず、別の場所でマッピングを行う場合、データを表すさまざまな方法を使用すると、変更してはならない場所のコードに影響を与える可能性があります。

score 1 · Accepted Answer

リポジトリはパターンです。これは、コードを可能な限り再利用するための標準化された方法で物事を実装する方法です。

score 1 · Accepted Answer

外部世界 (つまり、クライアントコード) のリポジトリは、以下を除いて DAL と同じです。

(1) 挿入/更新/削除メソッドは、データコンテナーオブジェクトをパラメーターとして持つように制限されています。

(2) 読み取り操作の場合、DAL のような単純な指定 (たとえば、GetByPK) または高度な指定が必要になる場合があります。

内部的には、データマッパーレイヤー (エンティティフレームワークコンテキストなど) と連携して、実際の CRUD 操作を実行します。

リポジトリパターンが意味しないもの:-

また、insert/update/delete メソッドによって実行されたすべてのメモリ内変更をデータベースにコミットする Insert/Update/Delete メソッドに加えて、リポジトリパターンのサンプル実装として別の Save メソッドを使用することに混乱する人もよく見かけます。リポジトリに確実に Save メソッドを含めることができますが、メモリ内の CUD (作成、更新、削除) と永続化メソッド (データベースで実際の書き込み/変更操作を実行する) を分離するリポジトリの責任ではありませんが、 Unit Of Work パターンの責任。

お役に立てれば！

score 1 · Accepted Answer

リポジトリパターンを使用する利点は、DAL コードを呼び出さずにビジネスレイヤーコードをテストできるように、データアクセスレイヤーをモックできることです。他にも大きな利点がありますが、これは私にとって非常に重要なようです.

score 1 · Accepted Answer

解釈と文脈がすべてです。それらは非常に似ている場合もあれば、実際には非常に異なる場合もありますが、ソリューションが機能する限り、名前の意味は何ですか!

score 0 · Accepted Answer

(単純な) ほとんどの場合、DAO はリポジトリの実装ですか?

私が理解している限り、DAOはdbアクセスを正確に処理しているようです（CRUD-選択はありませんか?!）が、リポジトリではデータアクセス全体を抽象化でき、おそらく複数のDAO（おそらく異なるデータソース）のファサードです。

私は正しい道を進んでいますか？

score 0 · Accepted Answer

私が理解していることから、それらは基本的に同じことを意味する可能性がありますが、命名は文脈によって異なります.

たとえば、IRepository インターフェイスを実装する Dal/Dao クラスがあるとします。

Dal/Dao はデータ層の用語です。アプリケーションの上位層は、リポジトリの観点から考えます。

score 0 · Accepted Answer

「リポジトリ」は特定のクラスであり、「DAL」はリポジトリ、DTO、ユーティリティクラス、およびその他の必要なもので構成される層全体であると主張できます。

asp.net-mvc - Repository Pattern vs DAL

12 に答える 12

Related

Reference