9

私は ASP.NET MVC で Web サイトを設計していて、リポジトリの正確な性質について少し混乱しているかもしれません。

NerdDinner の例に従って、私のサイトには、必要に応じてエンティティを提供する 1 つのリポジトリが必要です。ただし、関連するエンティティの特定のセットを処理する別のリポジトリを用意する必要があるとも聞きました....?

私のサイトの場合、多数のエンティティ (約 15 のテーブル) がありますが、大部分はすべて関連しています。プル/更新/削除などに必要なすべてのメソッドを含む1つのリポジトリを持つことは問題ありませんか?それとも分割する必要がありますか?

4

8 に答える 8

8

多くのエンティティに十分な汎用リポジトリを使用しています。

より複雑なものについては、これを必要なもので拡張するだけです。本当に両方の長所。

于 2009-09-24T16:26:13.103 に答える
8

ドメイン駆動設計では、リポジトリは集約ルートごとであるというルールがあります。詳細については、こちらをご覧ください。

読めば読むほど、NerdDinner はグッド プラクティスのコレクションとして見られることが多すぎると思いますが、絶対にそうではありません (特に NerdDinner リポジトリの議論については、こちらを参照してください)。そのため、人々はOxiteなどの他の MS の例を非難することがよくあります (ここでは:

開発者はこれに群がり、称賛し、盲目的にそれを福音として受け入れます。なぜなら、これは Microsoft から提供されたものだからです (既に順調に進んでいます)。悲しいことに、その精神を採用する開発者は、保守もテストも読み取りも不可能な混乱に陥ります。

）。

于 2009-09-24T18:43:02.890 に答える
5

タイプを受け入れる汎用リポジトリを使用する場合、複数を使用する理由はありません。

次のようなインターフェースを使用します。

public interface IRepository
{
    void Save<ENTITY>(ENTITY entity)
        where ENTITY : Entity;

    void Delete<ENTITY>(ENTITY entity)
        where ENTITY : Entity;

    ENTITY Load<ENTITY>(int id)
        where ENTITY : Entity;

    IQueryable<ENTITY> Query<ENTITY>()
        where ENTITY : Entity;

    IList<ENTITY> GetAll<ENTITY>()
        where ENTITY : Entity;

    IQueryable<ENTITY> Query<ENTITY>(IDomainQuery<ENTITY> whereQuery)
        where ENTITY : Entity;

    ENTITY Get<ENTITY>(int id) where ENTITY : Entity;

    IList<ENTITY> GetObjectsForIds<ENTITY>(string ids) where ENTITY : Entity;

    void Flush();
}

次に、次のようなコードで使用します。

var returnedObjects =  repository.GetAll<ObjectClass>();
var singleObject =  repository.Get<ObjectClass>(id);
于 2009-09-24T16:21:00.117 に答える
2

おそらく、リポジトリとは何かという言い回しがあなたを混乱させるかもしれないと思います。私にとって、リポジトリは、データが保存されるデータ ストレージ (つまり、MS SQL データベース) です。リポジトリ パターン

に従って、データストアごとに 1 つのリポジトリを設定することをお勧めします。ほとんどのプロジェクトで MS SQL を使用しているので、その DB のリポジトリを作成します (DAL/ORM に Subsonic を使用するのが好きで、リポジトリパターンと ActiveRecord パターンも実装しています)。次に、各テーブルのファクトリを作成します。これにより、Subsonic ActiveREcord クラスをまとめて抽象化することができます。

おそらく...

于 2009-09-24T16:22:05.060 に答える
2

各テーブルごとにリポジトリを作成しないでください。queen3 が言ったように、集約ルートごとにリポジトリを作成する必要があります。同様に、製品がカテゴリを持つことができる場合、カテゴリ リポジトリは製品のネストされたクラスである必要があります。ドメイン オブジェクトよりもドメイン ロジックの関係に従います。

于 2011-01-09T11:27:59.717 に答える
2

各データ オブジェクトのリポジトリを作成します。

たとえば、単純なライブラリ データベースには、次のリポジトリを含めることができます。

  • 作成者リポジトリ
  • ブックリポジトリ
  • パブリッシャーリポジトリ
于 2009-09-24T16:23:40.143 に答える
1

Queen3 の言うとおりです。その Aggregate Root 理論に従うことができます。私は基本的に、リポジトリをエンティティで考えずにグループ化しますが、構築中のアプリケーションで論理的にグループ化する方法を考えています。

例えば：

CustomersRepository
OrdersRepository
...

CustomerRepository には、GetCustomers、GetCustomer、AddCustomer、DeleteCustomer、AddCustomerContact、DeleteCustomerContact のメソッドを配置します。

OrdersRepository には、GetOrders、GetOrder、AddOrder、CancelOrder、CloneOrder、AddOrderDetail、DeleteOrderDetail などのメソッドを配置します。

于 2010-12-04T12:57:44.833 に答える
0

関連するエンティティのグループごとにリポジトリを使用する傾向があります。つまり、orderrepository には次のものが含まれる可能性があります。

注文、および注文詳細。

たとえば、Customer、CustomerProfile などのために別のものがあります。

これにより、リポジトリ クラスが整理されます。

デービー

于 2009-09-24T21:15:39.037 に答える