問題タブ [ddd-repositories]

次のリレーショナル テーブルのいくつかを含むフィットネス アプリケーションの db スキーマがあります - 顧客、セッション、ワークアウト。Cust から Sess は 1 対多、Sess からワークアウトは 1 対多です。EF 4 でリポジトリを作成する場合、1 つだけ作成する必要がありますか? 各テーブルは関連しているため、1 つのクエリですべてのテーブルのデータを公開できます。または、各テーブルが独自のリポジトリを保証しますか?

詳細: _customer は _session を作成し、_session は _workout に関連付けられます。_workout は、各セット、そのセットの重量、担当者の数、および身体部分が働いたことを追跡します。各 _session には複数のワークアウトが関連付けられています。同様に、各 _customer には複数の _sessionId があります。_customer が集約ルートのように見え、他のすべての情報はそこから取得できます。それで、すべてを実行する customer という名前の 1 つのリポジトリを作成します。顧客が欲しいだけでワークアウトなどには興味がないというシナリオについてはどうですか?顧客に電話するときにすべてが引き戻されますか? これが理にかなっていると思いますか？

どうもありがとう

ストゥ

現実の世界では、コントローラーはさまざまなデータベーステーブルやその他のデータストアからのデータを使用する必要がある可能性があります。例えば：

それで：

1. テーブルごとにリポジトリを使用する必要がありますか？

2. これが集合体の概念が作用するところだと思いますか？アグリゲートごとに1つのリポジトリが必要ですか？

3. コントローラのコンストラクタに必要な数のリポジトリを追加するだけですか？

4. これは私のデザインが間違っているというサインですか？

ノート：

IMemberインターフェースは、基本的に、メンバーシッププロバイダーに良い顔をするヘルパーオブジェクトを表します。つまり、すべてのコードを1か所に配置します。例えば：

それに関する1つの問題は、確かにこの種の出力をキャッシュすることです。別の質問が来るのを感じることができます。

編集：

私はDIにNinjectを使用しており、DI、DDD、およびTDD全体でかなり売れています。まあ、ある種。私も実用主義者になろうとしています...

Enterprise Library 5.0 を使用した DDD の実装を示すサンプル アプリケーションはありますか?

私たちは新しいプロジェクト (既存のアプリを書き直す) に取り組んでおり、ドメイン モデル / リポジトリの設計で問題が発生しています。

これは、ドメイン モデルの 2 つの重要な部分の (簡略化された) バージョンです。

ご覧のとおり、私はPostの抽象的な概念を持っています。これは、レビュー、ディスカッション、写真、ビデオなどのようなものです。投稿にはコメントを含めることもできます。

また、場所の抽象的な概念もあり、これは明らかに通り、都市、近隣などです。

さて、これは自然に私には 2 つの明確な集合根として見えました。

そこで、2 つのリポジトリを作成しました。1 つはPostRepositoryと呼ばれ、もう1 つはLocationRepositoryと呼ばれます。

これはすべて正常に機能していました。これら 2 つのリポジトリのいずれかを介して、任意のタイプの投稿 (またはコメント) を追加/取得し、任意のタイプの場所を追加/取得できます。

しかし、今は都市の「ランディング ページ」のシナリオにいます (たとえば)。

このページでは、基本的に「この場所のすべての投稿」を表示する必要があります。

それはどのように定義されていますか？まあ、投稿は（オプションで）場所でタグ付けできます。実装の詳細なので、データに深く入り込みたくはありませんが (それは DDD の目的ではないため)、基本的には、場所のシェープ ファイルによって特定の場所にどの投稿が含まれているかを判断するための地理空間インテリジェンスがあります。タグ付けされた投稿の緯度/経度。

しかし、境界を越えずにこの情報を取得するにはどうすればよいでしょうか?

どのリポジトリを使用しますか? 新しいものが必要ですか？

重要な場合 (または好奇心旺盛な場合)、これは SQL Server 2008 データベースと Entity Framework 4.0 を備えた Web アプリケーション (ASP.NET MVC) です。

説明が必要な場合はお知らせください。

編集

現在、ドメイン モデルを取得するために仕様パターンの修正版を使用しています。

たとえば、スコア >= 4 のすべてのレビューを取得する BLL のコードは次のとおりです。

しかし今、次のようなコードが必要です。

問題は、中間結合エンティティ (LocationPost - 多対多であるため) を追加せずに上記のクエリを実行する方法がわからず、それに Post ドメイン モデルに FK を追加することです。

でもそうする事で、私は総計の境界を越えていますね。

DataContext.GetTable() メソッドは、次のタイプのオブジェクトを返します。

System.Data.Linq.Table

そうすることで、テーブル全体を取得するためにデータベースへの呼び出しを発行していないと思います。そうしないと、LINQ はやや非効率的になります。

したがって、厳密に型指定された Datacontext クラス (dbDataContext など) にドリルダウンして、SQL Server の Customers テーブルを表す "Customers" プロパティなどのハンドルを取得するだけです。

その後、GetTable() によって返されたオブジェクトから IQueryable を取得できますが、データベースにはヒットしていません。つまり、私の「サービス レイヤー」コードは、Linq to Sql ではなく、LINQ to Objects になります。

これをすべて行うことで、必要なリポジトリの数を減らします。

質問：

上記の仮定は正しいですか？

ノート：

インターフェイスとジェネリックを使用してクエリを作成し、テスト可能にする方法を見つけようとしています。

したがって、@zowenの応答に沿って考えてください：

リポジトリ パターン: エンティティごとに 1 つのリポジトリ クラス?

実装しようとしています

厳密には必要ではないことはわかっていますが、学習曲線をたどり、自分に合ったアーキテクチャ オプションと自分の考え方を調べています。

私がやろうとしていること:

MongoDb の代わりに SQL Server に以下を実装しようとしています。

私が望むのは、GetTable() のハンドルを取得し、それに対してサービス レイヤー Linq コードを記述することです。

IMongoDatabase データベース変数と同等のものを取得するには、ラッパー インターフェイスを作成する必要があると思います。

ただし、問題は上記の問題であり、この他の問題ではありません。私が言うように、私はここで学んでいます。このムービーでは、製品コードが損なわれることはありません。

古いアプリケーションを書き直す必要があります。データアクセスにリポジトリパターンを使用し始め、必要な機能について可能な限り多くのテストを作成したいと思います。

偽のリポジトリやドメインモデル（できればゼロから始める）など、TDDのより複雑な例を含むいくつかのビデオ/ガイドをお勧めできますか？

私のドメインモデルがリポジトリを認識/気にする必要がない場合、.UpdateOrder(...)CRUD-Update をカプセル化する のような動作はどのようにリポジトリと連携しますか? ドメインサービス経由？

さて、私のリポジトリには、私の.UpdateOrder(...). それはいいです。しかし、誰かにリポジトリで Update メソッドを使用してほしくないので、エンティティでの動作を実行してもらいたい (代わりに UpdateOrder() を使用する)。私のドメインモデルが不変条件を満足する方法に似ていることを望みます-それは設計上(プライベートセットプロパティなど)-私のリポジトリはエンティティを「更新」/永続化するための代替方法を公開しません。

これは単にアクセス修飾子の問題であり、Repo パブリックに Update メソッドがないことで解決されます。または、「より良い」答えはありますか？DDD忍者を助けてください。

.net4（c＃）を使用した単純なeCartシステムに取り組んでいます。私は、作業単位パターン、リポジトリパターン、および永続性の無知について多くのことを読んできました。この方法でレイヤーを構築することの戦略と利点を理解していると思いますが、私のシンプルなアプリでは、それが必要かどうか、そして誰かが私のスコープに適したアーキテクチャを教えてくれるかどうか疑問に思っています。

間違っている場合は訂正してください。リポジトリを使用する主な利点は、DBへのアクセスを減らし、アプリケーションアーキテクチャをDBアーキテクチャから分離することです。IE-DBのパフォーマンスに優れていることは、アプリケーションの設計に必ずしも適しているとは限らないため、両方に最適なものを設計してから、2つの間にインターフェイスを作成することをお勧めします。

質問です。発生したビジネストランザクションは、発生したらすぐにDBに保存する必要があるため、リポジトリ内のデータをキューに入れてすぐに保存する意味はないようです。直接保存してみませんか？

私が見逃しているDDDの他の利点はありますか、それとも、発生するすべての単純なプロジェクトに対してそのような堅牢なアーキテクチャを構築することはエンジニアリングを超えているでしょうか？助けてくれてありがとう。

このシナリオについてパートナーと話し合っています。

これらの各エンティティは共通の情報を共有します: メール、BillingAddress、NormalAddress、性別、SSN など。

私は決定しました: Value オブジェクト Address と残りのプロパティを持つ Person エンティティ。このようにして、個人に関する特定の情報 (電子メール、性別、dateofbird) にアクセスしたい場合、それを取得するためにパブリッシャーまたは広告主のルート エンティティを経由する必要はありません (個人を集約ルートとして扱います)。

私のチームメイトは、抽象クラスを使用してそれを行うことを提案しています。広告主と発行者は、すべての共通プロパティを持つために Person 抽象クラスから継承します。

それを行うための最良の方法は何ですか?. お持ちの方はご案内ください。

ありがとう、ペドロ・デ・ラ・クルス

DDD を使用してタグ クラウドを実行したいのですが、オブジェクト タグは VO ですが、1 つの VO を挿入、編集、ロードすることはできません。自分のリポジトリがないためです。この問題を解決するにはどうすればよいですか? エンティティで VO タグを作成できることはわかっていますが、間違っています。これを解決するにはどうすればよいですか?