私は現在、ASP.NET MVCでウェブサイトを設計しており、リポジトリの正確な性質について少し混乱しています。ASP.NET MVC：リポジトリはいくつありますか？
NerdDinnerの例の後、私のサイトには、必要に応じてエンティティを提供する1つのリポジトリが必要です。しかし、私はまた、関連するエンティティの特定のセットを扱う異なるリポジトリを持つべきであると聞きました....
私のサイトの場合、多数のエンティティ（約15テーブル）がありますが、大部分はすべて関連しています。プル/アップデート/削除などに必要なすべてのメソッドが含まれているリポジトリを1つ持っていることをお勧めしますか？またはそれらを分割する必要がありますか？
私は、各データオブジェクトのリポジトリを作成します。
例えば、簡単なライブラリデータベースには、次のリポジトリが含まれている可能性が：
タイプを受け入れるジェネリックリポジトリを使用する場合は、複数のタイプを使用する理由はありません。私たちはこのようなインターフェースを使用
：私は多分、リポジトリであるものの言い回しがあなたを混乱かもしれないと思う
var returnedObjects = repository.GetAll<ObjectClass>();
var singleObject = repository.Get<ObjectClass>(id);
：
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();
}
は、このようなコードで使用しています。私にとってリポジトリは、データが格納されている場所のデータストレージ（つまり、MS SQLデータベース）です。
Repository Patternに続いて、各データストアごとに1つのリポジトリを設定することをおすすめします。私のプロジェクトのほとんどはMS SQLを使用しているので、そのデータベースのリポジトリを作成します（DAL/ORMにSubsonicを使用し、RepositryパターンとActiveRecordパターンも実装しています）、各テーブルのファクトリを作成します。これにより、Subsonic ActiveREcordクラスをまとめて抽象化することができます。参考になっザッツ
希望、おそらく...
私は各データストアのリポジトリを作成する声明について興味があります。私が多対多の "エンティティ"を持っていて、2つのIDを（主キーとして）格納する以外に何もしないのであればどうしますか？それ以外のリポジトリを作成する必要がありますか、または基本的なフェッチ/セーブメソッドの一部を別の関連リポジトリに含めることはできますか？ 私は、リポジトリが集約エンティティにもっと集中すべきだと思っていました。 – CitizenBane
すべての返信をお寄せいただきありがとうございます。この「ジェネリック」ルートは、私が初心者であるにもかかわらず興味を持っています。私はそれをどのように設定するかについてはわかりません。私のORMとしてエンティティフレームワークを使用して.... – Sergio
私は多くのために十分であるジェネリックリポジトリを使用しますエンティティ。
もっと複雑なものについては、私は単にを必要なものだけ拡張します。本当に両方の世界の最高。
ドメイン駆動型設計では、レポジトリは集約ルートごとにあるというルールがあります。あなたはそれについての詳細を読むことができますhere。
私が読むほど、NerdDinnerはあまりにもしばしば良いプラクティスのコレクションとみなされますが、それは絶対にありません（特にNerdDinnerリポジトリの説明についてはhereを参照してください）。人々はしばしばOxite（およびhereのような他のMSの例を非難する理由です：
賞賛 が、それがマイクロソフトから来るので盲目的福音 としてそれを受け入れる（それはその途中ですでによく だ開発者がそれに群がるだろう
、 ）。悲しいことに、その精神を採用するあらゆる 開発者は ）unmaintainble、 テスト不能と読めなく混乱
が残されます。
本当に..。 –
+1本当に良い最初のリンク！ –
関連するエンティティのグループごとにリポジトリを使用する傾向があります。つまり、オーダーリポジトリには次のものが含まれます：
オーダー、およびOrderDetail。
や顧客、言う、のために別のものを持っているだろう、CustomerProfileなど
これは、きちんとしたリポジトリのクラスを保持します。
デイビー
クイーン3が正しい、あなたはその集団のルート理論に従うことができます。私は基本的に、エンティティを考えていないリポジトリをグループ化しますが、ビルドしているアプリケーションで論理的にどのようにグループ化しているのですか。例えば
：
CustomersRepository
OrdersRepository
...
CustomerRepositoryで私はGetCustomersする方法を置く、GetCustomer、AddCustomer、DeleteCustomer、AddCustomerContact、DeleteCustomerContact。
OrdersRepositoryでは、GetOrders、GetOrder、AddOrder、CancelOrder、CloneOrder、AddOrderDetail、DeleteOrderDetailなどのメソッドを配置します。
各テーブルごとにリポジトリを作成しないでください。 queen3が言ったように、集約ルートごとにリポジトリを作成する必要があります。同様に、商品にカテゴリがある場合、カテゴリリポジトリは商品のネストされたクラスである必要があります。ドメインオブジェクトよりもドメインロジックの関係に従ってください。
この場合、リポジトリは特定の著者によってすべての本を返すだろうか？ – Sergio
書籍を依頼しているので、書籍保管室 – jao
が表示されます。たぶん、これについて間違った考え方をしているかもしれませんが、エンティティ（私の場合、エンティティの枠組み）の面では奇妙に思えます。私は助けができませんが、著者があれば、 。その点で、それらを別のリポジトリに分割するのは変です。 – Sergio