2

次のように、クラスUserとProfileをマップしようとしています。

public class User
{
    public long ID { get; set; }
    public string LoginName { get; set; }
    public Profile Profile { get; set; }
}

public class Profile
{
    //the ID is the same with User's ID 
    public long ID { get; protected set; }
    public string NickName { get; set; }
    public Gender Gender { get; set; }
}

したがって、これらは1対1の関係とコンポーネントの関係の両方としてマッピングできます。そして、何人かの人々がコンポーネントを評価し、1対1は悪い習慣だと思うのを見つけました、なぜですか？パフォーマンス上の理由で？ただし、多くのシナリオ（asp.net2.0メンバーシップなど）では、2つの別個のテーブルとして設計されています。

どのように選ぶべきですか？どの側面を考慮する必要がありますか？コンポーネントは「値オブジェクト」を意味しますが、エンティティではないことを知っていますが、これはさらにいくつかのことを意味しますか？

ps：そして、私をさらに混乱させたのは、現実の世界では1対1の関係であっても、多対1を使用する必要があるという意見です。

4

2 に答える 2

3

キーは、このクラスのユースケースにあるはずです。ASP.NET メンバーシップを例として取り上げないでください。その設計はひどいものです。

次の質問に答える必要があります。

  1. プロファイルはそれ自体のエンティティとして意味がありますか?
  2. ドメイン内の他の場所にプロファイルへの参照がありますか?
  3. プロファイルのないユーザーを持つことはできますか?
  4. 独自の動作はありますか？
  5. なんらかの理由でプロファイルを拡張 (継承) しますか?
  6. ほとんどのユースケースはユーザー (および ID だけでなくその LoginName) を処理するだけで、プロファイルは処理しませんか?

ほとんどの質問が真である場合、1 対 1 を使用する良いケースがあります (@Falcon には同意しません。これは実際には 1 対 1 の正当な使用法の 1 つです)。

それ以外の場合、コンポーネントは正常に機能します。ID がないため、そのプロパティを削除できます。

于 2010-12-02T18:15:59.527 に答える
2

どちらも使用しないでください。

一対一

ユーザーとプロファイルは異なるデータベース テーブルにありますが、どちらも相互に排他的な PK を共有しています: http://jagregory.com/writings/i-think-you-mean-a-many-to-one-sir/

リレーショナル データベースのかなり悪い設計手法です。これは面倒であり、必ずしもリレーションシップに制約を課すとは限りません。

成分

コンポーネントを使用して、乱雑なリレーショナル データベースからクリーンなオブジェクト モデルを取得できます。プロファイル データとユーザー データは両方とも同じデータベース テーブルに格納されますが、オブジェクト モデルでは分離する必要があります (コードから判断すると、必要に応じて)。遅延読み込みはおそらくサポートされていないため、データベース トラフィックが高くなります。

参照

私見、参照を使用する必要があります。1 対 1 のような概念ですが、ユーザーはプロファイルを参照します。プロファイルは独自のテーブルに格納でき、遅延ロード (パフォーマンス) が可能で、ユーザーに依存しません。

あなたの混乱について：私が提供したリンクを読んでください。技術的には、適切に設計されたデータベーススキームには多対1が必要です。これは技術的に可能であり、マッピングされるためです。私はそれが混乱していることを知っています。片側だけをマッピングする必要がある場合は、1 対 1 ではなく参照を考えてください。

于 2010-12-02T16:17:05.373 に答える