問題タブ [ddd-repositories]

Active Directory と SQL データベースの両方に永続的にアクセスする必要がある DDD ベースのシステムを構築しているという独特の状況があります。最初は、これは問題ではありませんでした。これは、次のような作業単位を持つ設計がセットアップされたためです。

リポジトリは次のようになります。

このセットアップでは、ロードとセーブで両方のデータ ストア間のマッピングが処理されます。これは、自分で作成したためです。作業単位はトランザクションを処理し、リポジトリが永続化のために使用する Linq To SQL データ コンテキストを含みます。Active Directory の部分は、インフラストラクチャに実装されたドメイン サービスによって処理され、各 Save() メソッドのリポジトリによって使用されました。Save() は、すべてのデータベース操作を行うためにデータ コンテキストと対話する役割を果たしました。

現在、これをエンティティ フレームワークに適応させ、POCO を活用しようとしています。理想的には、ドメイン オブジェクトはオブジェクト コンテキストによって追跡されているため、Save() メソッドは必要ありません。作業単位に Save() メソッドを追加して、オブジェクト コンテキストに変更を保存させるだけで済みます。新しいオブジェクトをコンテキストに登録します。新しい提案されたデザインは、次のようになります。

これにより、エンティティ フレームワークに関するデータ アクセスの問題は解決されますが、Active Directory 統合に関する問題は解決されません。以前はリポジトリの Save() メソッドにありましたが、現在はホームがありません。作業単位は、エンティティ フレームワークのデータ コンテキスト以外は何も認識しません。このロジックはどこに行くべきですか？この設計は、エンティティ フレームワークを使用するデータ ストアが 1 つしかない場合にのみ機能すると主張します。この問題に最善のアプローチをする方法はありますか? このロジックをどこに置くべきですか？

アンケートクリエーターを作成しています。質問票はセクションで構成され、セクションはページで構成され、ページは質問で構成されます。アンケートは集約ルートです。

セクション、ページ、および質問には、アンケート内で一意である必要があるショートコードと呼ばれるものを含めることができます（ただし、データベース内で一意ではないため、厳密にはIDではありません）。ショートコードを値オブジェクトにするつもりで、アンケート内で一意である必要があるというビジネスルールを含めたかったのですが、それを確実にする方法がわかりません。私の理解では、値オブジェクトはリポジトリまたはサービスレイヤーにアクセスしてはならないので、それが一意であるかどうかをどのように判断しますか？

助けてくれてありがとう。

ダレン

顧客を参照する注文がある場合、モデルには顧客の ID が含まれていますか、または値オブジェクトのような顧客オブジェクトのコピーが含まれていますか (DDD を考えてください)。

私はこれをしたいと思います：

今私はこれを行います：

フォームに渡されるビュー モデルに ID を含めるよりも、顧客オブジェクト全体を含める方が便利です。それ以外の場合は、注文が ID で参照するビューにベンダー情報を取得する方法を理解する必要があります。

これは、保存を呼び出すときに (最初のオプションを選択した場合)、注文オブジェクト内で見つけた顧客オブジェクトの処理方法をリポジトリが理解していることも意味します。2 番目のオプションを選択した場合は、ビュー モデル内のどこに配置するかを知る必要があります。

彼らが既存の顧客を選択することは確実です。ただし、表示フォーム上でその場で情報を変更したい場合もあります。コントローラーが顧客オブジェクトを抽出し、顧客の変更を個別にリポジトリに送信してから、注文に変更を送信し、顧客 ID を注文に保持するように主張することができます。

MVC および C# コードに固有の、次の DDD の概念に関する書籍またはブログ エントリを探しています。簡単な要約: 特別なリポジトリ メソッドからドメイン モデルを部分的に入力し、変更されたドメイン モデル プロパティのみをクライアントから JSON として送信します。

詳細:

• Customer オブジェクトはあるが、顧客番号と顧客名のみを含むドロップダウン リストが必要な場合は、特別な Repository メソッドを作成して Customer の完全な IList を返しますが、顧客 ID と顧客名のみを入力し、他のプロパティを null のままにするか、空の。これにより、ビュー モデル用に大量の特別なクラスを作成する必要がなくなります。

• Customer を編集している場合は、Customer オブジェクトをサーバーのセッション変数にキャッシュしてから、Customer DDL とクライアントの最初の顧客オブジェクトを含む View Model を JSON でシリアル化します。サーバ。JSON を MVC コントローラー メソッドの「オブジェクト パラメーター」(JSON からのオブジェクト パラメーターへのポスト データの再構築) に解決すると、非常に便利です。

• クライアント (JavaScript) は顧客オブジェクトをインスタンス化し、オブジェクトのプロパティを対応する同じ名前の HTML 入力ステートメントにバインドします。一方が変われば、もう一方が変わる。また、IList オブジェクトのテンプレートの概念も取り入れます。また、入力値が変更された場合 (イベント) に、顧客オブジェクト プロパティにダーティのフラグを立てます。

• 送信時に、変更された (ダーティな) オブジェクト プロパティのみが JSON にシリアル化され、サーバーに送り返されます。変更されていないプロパティは単に除外されます。サーバーは、キャッシュされた顧客オブジェクトを部分的な JSON 顧客オブジェクト (変更のみ) と結合し、結果の顧客オブジェクトをリポジトリに送信して永続化します。

それは本当に素晴らしいコンセプトです。理論について読んで、やることリストを手に入れたいと思います。

通常、リポジトリは次のいずれかの方法で実装されていることに気付きました。

方法 1

方法 2

方法 1 にはコレクションのセマンティクスがあります (これがリポジトリの定義方法です)。リポジトリからオブジェクトを取得して変更できます。ただし、コレクションを更新するようには指示しません。この方法でリポジトリを実装するには、メモリ内オブジェクトに加えられた変更を永続化するための別のメカニズムが必要です。私の知る限り、これは Unit of Work を使用して行われます。ただし、システムでトランザクション制御が必要な場合にのみ UoW が必要であると主張する人もいます。

方法 2 では、UoW が不要になります。Save() メソッドを呼び出すと、オブジェクトが新規で挿入する必要があるか、変更されて更新する必要があるかを判断できます。次に、データ マッパーを使用して、データベースへの変更を永続化します。これにより作業がはるかに楽になりますが、モデル化されたリポジトリにはコレクションのセマンティクスがありません。このモデルには DAO セマンティクスがあります。

私はこれについて本当に混乱しています。リポジトリがオブジェクトのメモリ内コレクションを模倣する場合、方法 1 に従ってモデル化する必要があります。

これについてどう思いますか？

モッシュ

ドメインモデルとリポジトリを別々のdllに含めることはできますか？

3層アーキテクチャでは、ドメインモデルをビジネスレイヤーに配置し、リポジトリをデータアクセスレイヤーに配置すると思います。

ドメインモデルはリポジトリを使用しますが、リポジトリはドメインモデルからオブジェクトを返す必要があるため、循環依存が発生することを理解しているため、混乱します。

私は上記の概念の1つ以上を誤解しているに違いありません。

しばらくの間私を悩ませてきたので、どんな説明でも大歓迎です、ありがとう。

対 2010/C#

ソリューションを整理し、リポジトリのインターフェースをホストするプロジェクトに名前を付けるためのオプションを探しています。

私が持っている: MyProject.Domain

MyProject.WebUI

MyProject.Repositories

MyProject.Interfaces??

これまでのところ、「Interfaces」は私が思いついた最高の名前ですが、好きではありません。アイデア/提案はありますか？

リポジトリ クラスはどの層に配置する必要がありますか? ドメインまたはインフラストラクチャ?

与えられた:

• レイヤー プレゼンテーション、ビジネス、およびデータを備えたアーキテクチャがあります。
• ドメイン駆動設計を適用しています。
• オブジェクト指向のクエリを作成できるオブジェクト リレーショナル マッパーを使用しています (例: HQL クエリを作成できる NHibernate)。

質問：

オブジェクト指向クエリをどのレイヤーに配置する必要がありますか?

私の考え：

それらをプレゼンテーション層に入れることは通常意味がないと思います。しかし、それらをビジネスレイヤーまたはデータレイヤーのどちらに配置するかはわかりません。

例 (NHibernate):

ビジネス ロジックにメソッド GetCustomersPossiblyInterestedIn(Product p) が必要だとします。次に、顧客が p と同じカテゴリの製品を購入済みの顧客オブジェクトを選択する複雑な HQL クエリを作成できます。

引数 a)

一方で、このクエリは明らかにビジネス ロジックであると言えます。なぜなら、顧客が同じカテゴリの製品を購入したかどうかに基づいて、ある製品に興味を持っている可能性があると見なされるという決定はビジネス上の決定だからです。同様の価格で同じカテゴリの複数の製品を購入した顧客を選択することもできます。

引数 b)

一方、ビジネス レイヤーはデータ レイヤーに依存すべきではないため、ビジネス レイヤーで NHibernate を直接使用すると警鐘が鳴ります。

考えられる解決策 1)

ビジネス層で使用する独自のオブジェクト指向クエリ言語を作成し、データ層で HQL に変換します。これにより、多くのオーバーヘッドが発生すると思います。解析されたクエリ言語の代わりにクエリ オブジェクトに基づくクエリ言語を使用する場合は、多少の労力を費やす可能性がありますが、私の反論は依然として当てはまります。

考えられる解決策 2)

NHibernate が HQL や ISession などで提供できる抽象化レベルはビジネス層に適合するため、ビジネス層で NHibernate を直接使用しても問題ありません。包む必要はありません。

どう思いますか？

編集:

密接に関連する議論については、Ayende Rahien による「Repository is the new Singleton」および「The false myth of encapsulated data access in the DAL」を参照してください。

UnitOfWork、Specification、Repository などの DDD パターンを提供する ncommon 1.1 で EF4 を動作させようとしています。

NCommon 構成行は、次の例外をスローしています。

SynchronizationLockException が発生しました

オブジェクト同期メソッドが、同期されていないコード ブロックから呼び出されました。

エラーをスローする実際のコードは次のとおりです。

これが私が実行しているコードです。