タグ付けされた質問 「repository-pattern」

リポジトリパターンを適切に使用する方法を理解しようとしています。アグリゲートルートの中心的な概念が次々と登場します。WebとStack Overflowの両方で集約ルートのヘルプを検索すると、それらについての議論と、ベース定義が含まれているはずのページへのデッドリンクが見つかります。 リポジトリパターンのコンテキストでは、集約ルートとは何ですか？

447 design-patterns  repository-pattern  ddd-repositories  aggregateroot 

データアクセスオブジェクト（DAO）とリポジトリパターンの違いは何ですか？Enterprise Java Beans（EJB3）、インフラストラクチャーとしてHibernate ORM、設計手法としてドメイン駆動設計（DDD）とテスト駆動開発（TDD）を使用してアプリケーションを開発しています。

423 hibernate  domain-driven-design  ejb-3.0  repository-pattern  data-access-layer 

序文：リレーショナルデータベースを使用するMVCアーキテクチャでリポジトリパターンを使用しようとしています。 最近、PHPでTDDの学習を開始しましたが、データベースが他のアプリケーションと非常に密接に結合していることに気付きました。リポジトリについて読み、IoCコンテナを使用してそれをコントローラに「挿入」しました。とてもクールなもの。しかし、リポジトリの設計に関するいくつかの実際的な質問があります。次の例を考えてみましょう。 <?php class DbUserRepository implements UserRepositoryInterface { protected $db; public function __construct($db) { $this->db = $db; } public function findAll() { } public function findById($id) { } public function findByName($name) { } public function create($user) { } public function remove($user) { } public function update($user) { } } 問題＃1：フィールドが多すぎる …

291 php  database  laravel  repository  repository-pattern 

OOP設計パターンで、リポジトリパターンとサービスレイヤーの違いは何ですか？ 私はASP.NET MVC 3アプリに取り組んでおり、これらのデザインパターンを理解しようとしていますが、私の脳はまだ理解していません...まだです!!

188 asp.net-mvc  oop  repository-pattern  service-layer 

ドメイン駆動設計では、エンティティがリポジトリに直接アクセスしてはならないという多くの合意があるようです。 これは、Eric Evans Domain Driven Designによるものですか。本から来たのですか、それとも他の場所から来ましたか その背後にある推論についての良い説明はどこにありますか？ 編集：明確にするため：データアクセスをビジネスロジックとは別のレイヤーに分離する従来のOOプラクティスについて話しているのではなく、DDDではエンティティがデータに話しかけることを想定していない特定の配置について話しているアクセス層（つまり、Repositoryオブジェクトへの参照を保持することは想定されていません） 更新：彼の答えが最も近いようだったので、私はBacceSRに賞金を与えましたが、私はまだこれについてかなり暗いです。そのような重要な原則ならば、オンラインのどこかにそれについての良い記事があるはずです、きっと？ 更新：2013年3月、質問への賛成票はこれに多くの関心があることを意味し、多くの回答があったとしても、人々がこれについてアイデアを持っているなら、まだまだ余裕があると思います。

185 oop  domain-driven-design  repository-pattern  s#arp-architecture 

DbContext、DbSet、および関連するインターフェースをさらに掘り下げているので、これらの実装の周りに別の「汎用」リポジトリを実装する必要があるのはなぜでしょうか。 DbContextとIDbSetが必要なすべてを行い、DbContext内に「作業単位」を含めるように見えます。 ここに何か欠けているのですか、それとも人々が理由なく別の依存関係の層を追加するのを楽しんでいるように見えますか？

145 repository-pattern  entity-framework-4.1  unit-of-work 

Laravelの優れたデザインパターンに関するT. Otwellの本を読んだ後、Laravel 4でアプリを作成しているときに、アプリケーションのすべてのテーブルのリポジトリを作成していることに気付きました。 私は次のテーブル構造になりました： 学生：ID、名前 コース：id、name、teacher_id 教師：ID、名前 割り当て：id、name、course_id スコア（学生と課題の間のピボットとして機能）：student_id、assignment_id、scores これらすべてのテーブルの検索、作成、更新、削除メソッドを備えたリポジトリクラスがあります。各リポジトリには、データベースと対話するEloquentモデルがあります。関係は、Laravelのドキュメント（http://laravel.com/docs/eloquent#relationships）のモデルで定義されています。 新しいコースを作成するときは、コースリポジトリのcreateメソッドを呼び出すだけです。そのコースには課題があるので、課題を作成するときに、コースの各生徒のスコアのテーブルにエントリも作成します。これはアサインメントリポジトリを通じて行います。これは、課題リポジトリが2つのEloquentモデル、つまり課題モデルと生徒モデルと通信することを意味します。 私の質問は次のとおりです：このアプリはおそらくサイズが大きくなり、より多くの関係が導入されるため、リポジトリ内の異なるEloquentモデルと通信することは良い習慣ですか、またはこれを代わりに他のリポジトリを使用して行うべきですか（割り当てリポジトリから他のリポジトリを呼び出すことを意味します） ）それともEloquentモデルで一緒に行う必要がありますか？ また、スコアテーブルを課題と生徒の間のピボットとして使用することは良い習慣ですか、それとも別の場所で行う必要がありますか？

120 oop  laravel  laravel-4  repository-pattern  eloquent 

ファクトリ、プロバイダー、サービスという用語の違いは何ですか？ NHibernateとそのリポジトリパターン（POCOクラスなど）に入るだけです。

114 oop  design-patterns  repository-pattern 

私のプロジェクトではSpring Data JPAリポジトリをしばらく使用しており、以下の点を知っています。 リポジトリインターフェースでは、findByCustomerNameAndPhone()（ドメインオブジェクトのフィールドであるcustomerNameと仮定して）などのメソッドを追加できphoneます。 次に、Springは、実行時に（アプリケーションの実行中に）上記のリポジトリインターフェースメソッドを実装することにより、実装を提供します。 これがどのようにコーディングされているかに興味があり、Spring JPAのソースコードとAPIを確認しましたが、以下の質問に対する回答が見つかりませんでした。 実行時に生成されるリポジトリ実装クラスと、実装および注入されるメソッドはどのようになっていますか？ Spring Data JPAはCGlibまたはバイトコード操作ライブラリを使用してメソッドを実装し、動的に注入しますか？ 上記のクエリを支援し、サポートされているドキュメントを提供してもらえますか？

111 java  spring  spring-data  repository-pattern  ddd-repositories 

私は常にリポジトリパターンを使用していましたが、最新のプロジェクトでは、それの使用と「作業単位」の実装を完璧にできるかどうかを確認したいと思いました。掘り始めると、「本当に必要なのか」という疑問を持ち始めました。 これはすべて、Stackoverflowに関するいくつかのコメントから始まります。AyendeRahienのブログへの投稿への痕跡が2つあります。 リポジトリは新しいシングルトンです ask-ayende-life-without-repositories-the-they-worth-living これはおそらくいつまでも話される可能性があり、アプリケーションによって異なります。私が知りたいのは、 このアプローチはEntity Frameworkプロジェクトに適していますか？ このアプローチを使用して、ビジネスロジックはまだサービスレイヤー、または拡張メソッドにありますか（以下で説明するように、拡張メソッドはNHibセッションを使用しています）。 これは、拡張メソッドを使用して簡単に実行できます。クリーンでシンプルで再利用可能。 public static IEnumerable GetAll( this ISession instance, Expression<Func<T, bool>> where) where T : class { return instance.QueryOver().Where(where).List(); } このアプローチをNinjectDIとして使用してContext、インターフェイスを作成し、それをコントローラーに挿入する必要がありますか？

95 entity-framework  design-patterns  architecture  aop  repository-pattern 

私はかなりの時間をかけて、典型的なリポジトリパターン（特殊なクエリのメソッドのリストの増加など）によって提示される問題の適切な解決策を探していました。http：//ayende.com/blog/3955/repository-を参照してください。 is-the-new-singleton）。 特に仕様パターンを使用することで、コマンドクエリを使用するアイデアが本当に気に入っています。ただし、仕様に関する私の問題は、単純な選択（基本的にはwhere句）の基準にのみ関連し、結合、グループ化、サブセットの選択または射影などのクエリの他の問題を処理しないことです。基本的に、多くのクエリが正しいデータセットを取得するために通過しなければならないすべての追加のフープ。 （注：クエリオブジェクトとも呼ばれるコマンドパターンのように、「コマンド」という用語を使用します。クエリとコマンド（更新、削除、インサート）） したがって、クエリ全体をカプセル化する代替手段を探していますが、それでも、スパゲッティリポジトリをコマンドクラスの急増に交換するだけではないほど十分に柔軟性があります。 私は、たとえばLinqspecsを使用しましたが、選択基準に意味のある名前を割り当てることができることに価値があると感じましたが、それだけでは不十分です。おそらく、私は複数のアプローチを組み合わせた混合ソリューションを探しています。 この問題に対処するため、または別の問題に対処するために他の人が開発した可能性のある解決策を探していますが、これらの要件は満たしています。リンクされた記事では、AyendeがnHibernateコンテキストを直接使用することを提案していますが、クエリ情報も含める必要があるため、ビジネスレイヤーが大幅に複雑になっているように感じます。 待機期間が過ぎ次第、私はこれについて報奨金を提供します。だから、良い説明を付けてあなたの解決策を報奨に値するものにしてください、そして私は最良の解決策を選び、そしてランナーを賛成します。 注：私はORMベースの何かを探しています。EFやnHibernateを明示的に指定する必要はありませんが、これらは最も一般的であり、最も適しています。それが他のORMに簡単に適用できる場合は、ボーナスになります。Linq互換性もいいです。 更新：ここに良い提案があまりないことに本当に驚いています。人々は完全にCQRSであるか、完全にリポジトリキャンプにいるようです。私のアプリのほとんどは、CQRSを保証するほど複雑ではありません（ほとんどのCQRS擁護者が使用するべきではないとすぐに言っています）。 更新：ここで少し混乱があるようです。私は新しいデータアクセステクノロジーを探しているのではなく、ビジネスとデータ間の適切に設計されたインターフェイスを探しています。 理想的には、私が探しているのは、クエリオブジェクト、仕様パターン、およびリポジトリの間のある種のクロスです。上で述べたように、仕様パターンはwhere句の側面のみを扱い、結合や副選択などのクエリの他の側面は扱いません。リポジトリはクエリ全体を扱いますが、しばらくすると手に負えなくなります。クエリオブジェクトもクエリ全体を処理しますが、単純にリポジトリをクエリオブジェクトの爆発に置き換えたくありません。

90 c#  repository-pattern  command-pattern  specification-pattern 

このコードがLINQ to SQLで機能するのを見ましたが、Entity Frameworkを使用すると、次のエラーがスローされます。 LINQ to Entitiesはメソッド 'System.Linq.IQueryable'1 [MyProject.Models.CommunityFeatures] GetCommunityFeatures（）'メソッドを認識せず、このメソッドはストア式に変換できません。` リポジトリコードはこれです： public IQueryable<Models.Estate> GetEstates() { return from e in entity.Estates let AllCommFeat = GetCommunityFeatures() let AllHomeFeat = GetHomeFeatures() select new Models.Estate { EstateId = e.EstateId, AllHomeFeatures = new LazyList<HomeFeatures>(AllHomeFeat), AllCommunityFeatures = new LazyList<CommunityFeatures>(AllCommFeat) }; } public IQueryable<Models.CommunityFeatures> GetCommunityFeatures() { return …

89 c#  entity-framework  linq-to-entities  repository-pattern 

リポジトリをどのようにグループ化する必要があるのでしょうか。asp.net mvcや私の本で見た例のように、基本的にデータベーステーブルごとに1つのリポジトリを使用します。しかし、それは多くのリポジトリのように思われるため、後でモックなどのために多くのリポジトリを呼び出す必要があります。 だから私はそれらをグループ化する必要があると思います。ただし、それらをグループ化する方法がわかりません。 今、私はすべての登録を処理するための登録リポジトリを作成しました。ただし、更新する必要があるテーブルが4つあり、これを行うために3つのリポジトリがあります。 たとえば、テーブルの1つはライセンステーブルです。彼らが登録するとき、私は彼らの鍵を見て、データベースに存在するかどうかを確認します。登録以外の場所で、このライセンスキーまたはそのテーブルの何かを確認する必要がある場合はどうなりますか？ 1つの場所はログインである可能性があります（キーの有効期限が切れていないかどうかを確認してください）。 それで、私はこの状況で何をしますか？コードを書き直します（DRYを破ります）？これらの2つのリポジトリを一緒にマージして、他の時点でメソッドが不要になることを期待してください（userNameが使用されているかどうかをチェックするメソッドがあるかもしれませんが、別の場所で必要になるかもしれません）。 また、それらをマージする場合、サイトの2つの異なる部分のすべてのロジックが長くなり、ValidateLogin（）、ValdiateRegistrationForm（）のような名前が必要になるため、同じリポジトリに2つのサービスレイヤーを配置する必要があります。 、ValdiateLoginRetrievePassword（）など。 または、とにかくリポジトリを呼び出して、奇妙な名前を付けますか？ アプリケーションの多くの場所で使用できるように、十分に一般的な名前のリポジトリを作成するのは難しいようですが、それでも意味があります。リポジトリ内の別のリポジトリを呼び出すことは良い習慣ではないと思いますか？

86 c#  .net  asp.net  asp.net-mvc  repository-pattern