7

リポジトリとは何かについてかなりのトピックを読みましたが、まだ私を悩ませているものはほとんどありません。

私の理解では、 Repositoryと従来のデータ アクセス レイヤーの唯一の違いは、Repositoryのクエリ構築機能 (つまり、クエリ オブジェクト パターン) です。しかし、次のRepository Patternの定義を読むと、 Query Object patternを実装しなくてもRepositoryを使用できるようです。

a) 差出人:

リポジトリは、オブジェクトをハンドオフしてフェッチする単一のポイントです。また、ストレージとの通信の開始と終了の境界でもあります。

上記の引用は、リポジトリが DAL へのエントリ ポイントであることを示唆していると思います。言い換えれば、引用によると、DAL コンシューマー (サービス層など) はRepository経由で DAL と通信します。しかし、代わりにデータ コンテキストが DAL へのエントリ ポイントを表すべきではありません (したがって、リポジトリはデータ コンテキスト内に存在する必要があります)。

b) から:

リポジトリを従来のデータ アクセス レイヤーと区別する主な点は、.Net の IList と同様に、すべての意図と目的がコレクション セマンティックであることです。

ほとんどの従来の DAL には、コレクションを返すメソッド (たとえばList<Customer> GetAllCustomers()) もありませんか? では、リポジトリのコレクションに似たセマンティックは、従来の DAL のコレクションに似たセマンティックとどのように異なるのでしょうか?

c) から:

簡単に言えば、Repository パターンとは、永続レイヤーを抽象化し、コレクションとしてマスクすることを意味します。このように、アプリケーションはデータベースやその他の永続性の詳細を気にせず、抽象化 (通常はインターフェイスとしてコーディングされます) のみを扱います。

私の知る限り、上記の定義は従来の DALの定義と何ら変わりはありません。したがって、Repositoryの実装が、コレクションのようなセマンティクスを持ち、ドメイン オブジェクトをデータベース アクセス コードの詳細から分離するという 2 つの機能のみを実行する場合、従来の DALとどう違うのでしょうか? 言い換えれば、それはまだRepositoryと呼ばれるべきですか?

d) 以下のインターフェースを単なる通常のDAL インターフェースではなく、 Repository インターフェースにしている理由は何ですか?

から：

public interface IPostsRepository
    {
        void Save(Post mypost);
        Post Get(int id);
        PaginatedResult<Post> List(int skip,int pageSize);
        PaginatedResult<Post> SearchByTitle(string title,int skip,int pageSize);
    }

ありがとうございました

4

1 に答える 1

5

参考までに、ここで非常によく似た質問をしたところ、いくつかの優れた回答が得られました。

肝心なのは、アーキテクチャの複雑さに依存しているように見えるということです。リポジトリ パターンは、さまざまな種類のデータ ストアにアクセスする必要がある場合に抽象化のレイヤーを作成するのに最も役立ちます。つまり、一部のデータはエンティティ フレームワークにあり、一部はファイル システム上にあるなどです。単一のデータ ストア (つまり、SQL Server や Oracle などのすべてのデータ) はそれほど重要ではありません。その時点で、Entity Framework コンテキスト オブジェクトのようなものが、エンティティ オブジェクトのリポジトリとして機能します。

于 2012-11-01T18:55:43.260 に答える