2

私はDDD（ドメイン駆動設計）の方法で物事をやろうとしています。そして、男の子は私が苦労しますか。私が読んだすべての本で、認証は問題ではなく、言及されていません!

ユーザーの登録とログイン、salted パスワードの作成などを担当する独自の認証およびメンバーシップ サービスを作成しました。.NET のメンバーシップ プロバイダーは使用しませんが、フォーム認証に依存しています。

Username、E-Mail、PasswordHash、ApprovalStatus などを保持する User モデルを実装しました。

ここで、ドメイン モデルの残りの部分はユーザーに関係するべきではないと思います。Person とその関連データをモデル化するために使用されるクラス Person があります。そのため、ユーザーおよび非ユーザーからの個人データをモデル化するために使用できます。Company タイプのオブジェクトは、Users ではなく Persons と連携します。また、アクティビティはユーザーではなく人に割り当てられます。

質問は、Person モデルを User モデルに関連付けるにはどうすればよいですか? 2 つのモデルのいずれかでお互いを参照する必要はありません。PersonUser というリレーションシップ モデルを作成し、現在認証されているユーザーの人物オブジェクトを取得する追加のサービスを作成する必要がありますか?

4

1 に答える 1

2

あなたが提示したものから判断すると、いくつかの既知の事実があります。

  1. すべてのユーザーは人です
  2. すべての人がユーザーであるとは限りません

その場合は、個人モデルを拡張して null 許容の UserId フィールドを含め、ユーザーでもある個人の個人にユーザーを関連付けることができるようにします。

ここで、個人モデルにいくつかの「Fetch」メソッドがあると仮定します..ID、名前、部門などで個人を取得します...

fetch メソッドをオーバーロード (または別のメソッドを作成) して、User から person オブジェクトも取得します (これは、id または foll user オブジェクトのいずれかです)。

public IPerson Fetch(IUser user) {}

もちろん、すべてのユーザーが個人でもあるという事実はわかっているので、ユーザー オブジェクトを拡張して個人のプロパティを含めることに個人的には何の害も反則もないと思います...

public interface IUser 
{
   ...
   IPerson Person { get; set; }
}

次に、いつものようにユーザーオブジェクトを返すことができます..おそらく、ユーザーの人物フィールドのファンキーな遅延ロードを行うか、ユーザーオブジェクトをフェッチするときに両方を入力します。

User <-> Person の「マッピング」テーブルを作成することで、上で概説した以上のものが得られるかどうかはわかりません (ただし、データの非正規化については、筋金入りの DBA から賞賛を得るでしょう)。私にとっては、同じ効果を得るために参加する追加のテーブルにすぎません。

于 2009-05-07T12:46:36.210 に答える