8

NHibernate を使用して非常に基本的な ASP.NET MVC アプリをモデリングしていますが、設計に行き詰まっているようです。ここに私のモデルのスケッチがあります：

モデル1

ご覧のとおり、これは非常に基本的なことですが、いくつか懸念事項があります。ユーザー ルート エンティティと組織ルート エンティティは、2 つの 1 対多の関係を介して同じ Organization_Users エンティティの子にアクセスしています。これは正しくないようで、集約境界を破っていると思います。このモデルは私にはにおいがしますが、次のようなコードが必要なので、このアイデアが気に入っています。

var user = userRepository.Load(1);
var list = user.Organizations; // All the organizations the user is a part of.

と

var org = orgRepository.Load(1);
var list = org.Users; // All the users in an organization.

また、フラグ付きやロールなどのテーブル内の追加データは、組織エンティティによって使用されます。これはデザインが悪いのでしょうか？素晴らしいと思うことがあれば。私はまだ、DDD の考え方について理解を深めようとしています。ありがとう

4

6 に答える 6

4

これは典型的な多対多の関係です。そして、Organization_Usersテーブルはブリッジテーブルです。実際、NHibernateおよび他のすべてのORMツールには、ブリッジテーブルをサポートする機能が組み込まれています。

この問題は、アプリケーションレベルではなく、データモデリングレベルで解決する必要があります。データモデルを分析する必要があり、多対多の関係を回避することをお勧めします（ドメインモデルの必要性でない場合は、多対多の関係を回避するようにしてください）。

まず最初に、ドメインエンティティをマッピングするためにデータモデルの多対多の関係が必要であることを確認する必要があります。これを実行すると、図に示されているモデルは、アプリケーションレベルでこれらの関係をマッピングするのに問題ありません。

于 2009-07-09T06:45:29.010 に答える
2

あなたのモデルは大丈夫だと思います。私は通常、ドメイン集約ルートについて考えるとき、内部実装ではなく、公開されているものの観点から考えます。人間関係では、人間関係の中でどのエンティティが「ズボンをはいている」かを考えます。つまり、ユーザーを組織に追加するのがより自然ですか、それとも組織をユーザーに追加するのがより自然ですか？この場合、両方が理にかなっている可能性があり、ユーザーは組織に参加します。組織は、メンバーシップのユーザーを受け入れます。

ドメインがユーザーの観点から関係を認識している場合は、ユーザーの関係を維持（追加、削除など）するメソッドを配置し、組織の読み取り専用コレクションを公開できます。

2番目のデザインへの応答（元の質問を編集した方がよかったでしょう）：私はそれがまったく好きではありません。あなたのオリジナルのデザインは素晴らしいです。クラスを設計するときにデータベースを必ずしも無視するわけではありません。優れた設計では、ドメインを正確にモデル化し、リレーショナルデータベースに簡単に実装できる必要があります。スイートスポットに到達するには、両方向に妥協しなければならない場合があります。骨材の境界を破るための刑務所の用語はありません。:-)

于 2009-07-09T17:31:11.973 に答える
2

私はあなたの最初のモデルと同様のアプローチを何度か使用しました。このアプローチの1つの欠点は、ドメインのRoleフィールドとFlagedフィールドを処理するために、ドメインにOganizationUserクラスを作成する必要があることです。これにより、コードにこのようなものが残ります。

var user = userRepository.Load(1);
var list = user.OrganizationUsers; // All the organizations the user is a part of including their role and flagged values.

var organization = list[0].Organization;

*すべてのユーザー組織を頻繁に繰り返す場合は、 OrganizitionUserとともにOrganizationエンティティを熱心にロードすることをお勧めします。

送信した2番目のデザインでは、 OrganizationUserにユーザーを追加しなくてもOrgUserDetailsにユーザーを追加できるようです。それは私のドメインからサポートしたいものではないようです。

于 2009-07-09T22:28:49.703 に答える
2

DDD で最初に考慮すべきことは次のとおりです。

  • データベーススキーマを忘れてください（データベースはありません！）
  • ドメインの観点から、それらのエンティティに対してどのようなアクションを実行しますか?
于 2009-07-09T16:25:14.477 に答える
1

私の理解は次のとおりです。

ユーザーは、0 対多の組織に所属できます。AND 組織は 0 対多のユーザーで構成されます。

どちらも正しいですか？もしそうなら、それは私には多対多のように聞こえます。

多対多では、そのギャップを埋めるために何らかの関係のようなオブジェクトが必要です。問題は、ドメインに user_organization がないことです。

これは、ドメイン自体の一部として user_organization を持つべきではないと私に思わせます。実装の詳細のように感じます。

一方、組織内のユーザーを保持し、ユーザーの役割やその関係に固有のその他の情報を保存する名簿を持つことは、ドメインでは理にかなっているかもしれません。

于 2009-07-09T17:14:18.920 に答える
0

皆様のご回答ありがとうございます。彼らはとても役に立ちました。

モデルについてもう少し考えているうちに、もっと良いと思う新しいものをスケッチしました。

代替テキスト

私の考えはこれでした：

  1. ユーザーがサイトにログインすると、システムは自分のアカウントを見つけて、所属している組織のリストを返し、user_organizationsオブジェクトからこの情報を取得します。

  2. ユーザーが離れている組織の1つをクリックすると、組織のコントロールパネルに移動します。

  3. 次に、選択した組織は、org_user_detailsでそのユーザーの役割を検索して、その組織のコントロールパネルへのユーザーのアクセス権を確認します。

それは理にかなっていますか？:)

モデルではそれでいいと思いますが、DBの実装については疑問があります。私はそれについて心配するべきではないことを知っていますが、私はまだ私の悪い習慣を破ることができません！user_organizationsオブジェクトとorg_user_detailsオブジェクトにある種の重複データがあることがわかります。私はDBプロではありませんが、それは悪いDB設計ですか？代わりに、user_organizationsとorg_user_detailsのデータを最初の投稿のようなテーブルに結合し、NHibernateに、ユーザーはそれを多対多の関係と見なし、組織はそれを1対多の関係と見なすように指示する必要があります。 ？それは私がシステムをだましているように聞こえます。これについて本当に混乱しているようでしたらごめんなさい。

これについてどう思いますか？私はこれを考えすぎていますか？：P

于 2009-07-09T18:31:53.067 に答える