問題タブ [ddd-repositories]

何かを明確にする必要があります。

Person Aggreagate、2 VO（Country、StateProvince）があります。

プレゼンテーション層にすべての国をロードしたい（MVCを使用しています）

Evanは、ルートエンティティを操作するためにリポジトリ（IPersonRepository）のみを使用すると言います（常に集約ルートへの参照のみを返す必要があります）

これを解決するために私が通常行うこと：

このメソッドをIPersonRepositoryに追加します

インフラレイヤーでは、次のようなドメインインターフェイスを実装します。

私のパートナーは私が間違っていると言います。

時々あなたはいくつかのタスクを達成するためにあなたのドメインモデルを犠牲にしなければなりません

これを行うための最良の方法は何ですか？

コードでお願いします！:)

プロジェクト構造については次のとおりです。これらはすべて個別のプロジェクトです。そのようにするように言われたので、私の選択ではありません。

これが私の質問です。コントローラーをダイエットに保つことがベストプラクティスであり、モデル/ビューモデルは愚かであるべきであるため、プロジェクト構造のサービスレイヤー部分を導入することを読んでいます。今の実際の質問; これは良いアプローチですか、それとも自分のためにあまりにも多くの作業を作成していますか?

したがって、製品やカテゴリ、またはその他のエンティティに対していくつかの CRUD 操作を行いたい場合、リポジトリはサービス層/ビジネス ロジック層からインスタンス化する必要がありますか?

いくつかの入力をお願いします??

次の推奨事項は何ですか。私はこのような構造をしています。--ApplicationServices

- ドメイン

--Infrastructure.Backends

--Infrastructure.Data

--MVCWebアプリケーション

edmxファイルと生成されたPOCOをどこに置くべきですか？私はドメインを考えていました。その場合、アプリケーションサービスはリポジトリを呼び出し、MVCアプリケーションのコントローラーにデータを返します。これは正しい考え方ですか？

リポジトリインターフェイスとリポジトリの実装はどこにありますか？

リポジトリ パターンについて調べた例には、エラー処理が含まれていません。どうしてこれなの？たとえば、私はこれを持っているとしましょう:

制約に違反したインスタンス。DbUpdateException をキャッチします...リポジトリ自体にない場合、このエラー処理はどこで行われますか?

私は現在、複数のデータソースを使用して必要なデータを消費するシステムを設計中です。以下に示す概念をモデル化しようとしています（画像を投稿しますが、十分なポイントがありません！）。そこでは、顧客が多くの製品と関連付けることができます。顧客は「顧客サブシステム」に保存され、製品と顧客製品は「製品サブシステム」に保存されます。

「顧客」エンティティは、Webサービスを介してアクセスする必要があるシステムに物理的に永続化されます。「ConsumerProduct」および「Product」エンティティは、NHibernateをORMとして使用して、SQLデータベースに永続化されます。

設計の一環として、リポジトリを使用して、ドメインモデルからデータ永続化テクノロジを抽象化することを計画していました。したがって、ICustomerRepository、ICustomerProductRepository、IProductRepositoryの3つのリポジトリインターフェイスがあります。次に、CustomerProductおよびProductリポジトリ用の具体的なNHibernate実装と、Customerリポジトリ用の具体的なWebサービスアクセス実装を作成します。

私が苦労しているのは、さまざまなサブシステムで永続化されているエンティティがどのように相互作用するかです。理想的には、CustomerProductエンティティがCustomerオブジェクトを返す物理的な「Customer」プロパティを持つリッチドメインモデルが必要です。ただし、顧客エンティティには別のデータストアからアクセスする必要があるため、これがどのように機能するかわかりません。

この問題を解決するために私が見ることができる唯一の方法は、CustomerProductエンティティで顧客への完全な参照を維持せず、代わりに参照を保持することです。その後、顧客への参照を取得する必要があるたびに、顧客を経由します。リポジトリ。

この問題を解決する方法について誰かが提案できる提案をいただければ幸いです。

Windsor は使用するのに最適な DI/IOC ツールであると読んだので、試してみることにしました。MVC プロジェクトを使用してすべてを接続する方法の多くの例を見ていますが、DDD モデルの他のレイヤーを使用していくつかの依存関係マッピングを接続する必要があります。

DbContext を注入する必要があるリポジトリ ベースがあります。私は DbContext から派生したクラスを持っているので、それが注入する必要があるクラスになります。いっそのこと、私はそれのためのインターフェースを作ることができます。IAppDBContext.

Global.asax前に言ったように、すべてのサンプルには、Web プロジェクトのファイルで配線が行われています。通常のクラス ライブラリ プロジェクトでは、どこに配線しますか?

ドメインモデルがテーブル駆動型でない場合、つまりドメインオブジェクトがデータベーススキーマと一致しない場合に、POCOをLinq-to-Sqlで機能させる方法を見つけるのに苦労しています。

たとえば、私のドメインレイヤーには、RecurrenceタイプのRecurrenceプロパティを持つAppointmentオブジェクトがあります。これは、特定の再発パターンに基づいたいくつかのサブクラスを持つ基本クラスです。

私のデータベースでは、Appointmentレコードとその繰り返しの間に常に1対1の関係がある場合、個別のAppointmentRecurrencesテーブルを持つことは意味がありません。したがって、AppointmentsテーブルにはRecurrenceType列とRecurrenceValue列があります。RecurrenceTypeは、RecurrenceTypesテーブルと外部キーの関係にあります。これは、Recurrence Type（パターン）とAppointmentsテーブルの間に1対多の関係があるためです。

Linq-to-Sqlでこれら2つのモデル間に適切なマッピングを作成する方法がない限り、コードのインピーダンスの不一致を手動で解決する必要があります。

これは、仕様パターンを使用してデータベースにクエリを実行する場合、さらに困難になります。たとえば、現在の予定のリストを返したい場合は、次の式を使用する仕様オブジェクトを簡単に作成できますappt => appt.Recurrence.IsDue。ただし、式のソースタイプはL2Sが認識するものではないため（たとえば、L2Sエンティティではないため）、これはLinq-to-SQLスペースに変換されません。

では、ドメインモデルをサポートするためにLinq-to-SQLで複雑なマッピングを作成するにはどうすればよいですか？

または、この場合、仕様パターンを実装するためのより良い方法はありますか？ドメインオブジェクトとL2Sエンティティの両方で（パーシャルを介して）実装されるインターフェイスを使用することを考えましたが、2つのオブジェクトグラフのインピーダンスの不一致では不可能です。

提案？

Active RecordパターンとRepositoryパターンを最大限に活用しようとする次のアプローチの欠点 (たとえば、テスト容易性の観点から) は何でしょうか?

各永続オブジェクトは、save() および delete() メソッドを公開しますが、それ自体をロードしたり、同様のオブジェクトのリストをロードしたりするための静的メソッドはありません。上位層からのロードは、永続オブジェクトの静的メソッドを回避するために、リポジトリを直接呼び出すことによって行われます。

「save()」および「delete()」メソッドは単なるファサードであり、リポジトリに委譲されます。

テスト可能性は本当にこのアプローチの問題ですか? 純粋なアクティブ レコード アプローチを使用しても、データベース ロジックがビジネス ロジック全体のほんの一部を表している情報システムはありますか。

EDIT：このアプローチは、永続オブジェクトが「save（）」と「delete（）」を実装するAbstractPersistentObjectから継承する必要があり、ビジネスの継承を防ぎますが、ビジネスの継承を避け、構成に置き換える方が良いと読みました。デメリットじゃなくてメリットかも…？

EDIT2：おそらく、この記事は私が解決しようとしている問題をよりよく説明するでしょう：http://moleseyhill.com/blog/2009/07/13/active-record-verses-repository/

「FormSubmission」エンティティと1対1のマッピングを持つ「Interview」エンティティがあります。Interviewエンティティは、いわば支配的な側面であり、マッピングは次のとおりです。

両方のエンティティは、インタビューがアグリゲートルートとして機能するアグリゲートの一部です。Interviewエンティティを介してFormSubmissionを保存/更新/削除しようとしているため、関連付けのInterviewの終わりをcascade="all-delete-orphan"としてマップしました。たとえば、次のように新しいFormSubmissionを作成できます。

...これは問題なく機能し、FormSubmissionが保存されます。ただし、次のように実行しようとしているFormSubmissionを削除できないようです。

...しかし、これはFormSubmissionを削除していないようです。アソシエーションの両側にnullを割り当ててみました：

FormSubmission側でcascade="all-delete-orphan"を設定しようとしましたが、何も機能しないようです。私は何が欠けていますか？

Domain Drive Design の最初の実験を始めたばかりで、NWorkspace パターンを利用しています。このパターンは非常に理にかなっているように見えますが、このパターンがうまく使用されているか、公的に文書化されている場所の例をあまり見つけることができませんでした。実装に入る前に、誰かがこのパターンを使用して成功したかどうか、または誰かが私が学ぶことができるオープンソース プロジェクトで NWorkspace が使用されている参照を教えてくれるかどうかを知りたい. また、私が知っておくべき、このパターンよりも優れた、またはよりよく知られている代替手段はありますか?

NWorkspace の簡単な背景

NWorkspace に慣れていない人のために説明すると、これはJimmy Nissonによって導入された、クエリと永続化の責任を抽象化するパターンです。Jimmy Nilsson は著書 Applying Domain-Driven Design and Patterns で、NWorkspace を使用して DDD リポジトリのインフラストラクチャ部分を抽象化し、永続性に関してリポジトリ間の原子性を実行するメカニズムを提供する方法を示しています。