3

はい、私はタイトルが私の現在の考え方に欠陥があることを示唆していることに同意します。しかし、再び正気に到達することを期待して、これが私がこの残念な状態に到達した方法です。

サブジェクトオブジェクトはアドレスであり、サブジェクトアプリケーションには3つの地域オフィスに数百人の従業員がいます。このコンテキストでは、（3）アドレスをエンティティオブジェクトとして扱い、それらの3つのアドレスのみをデータベースに保持すると便利です。

もちろん、アプリケーションは何千もの顧客にサービスを提供するため、従業員には雇用があります。このコンテキストでは、アドレスをValueObjectとして扱う方が便利です。

今、私は、企業と人々が持っている共通の特性を維持するためのパーティーパターンを持ちたいと思っています。

最後のファクトイド-値オブジェクトに期待できることを実行するValueObjectクラス（つまり、パブリックプロパティに基づいて同等性を決定する）とEntityクラス（オブジェクトが永続的である場合はIDに基づく同等性）があります。

じゃあ何をすればいいの？次のクラスのアイデアで遊んでいたのですが、これを聞いて、どのような答えが返ってくるのか見てみようと思いました...

class Address : ValueObject, IHaveAddress{
    Line 1 {get;}
    ... etc
    Address {get{return this;}} // this has an awkward smell
}

class EntityAddress : Entity<int>, IHaveAddress{
    Address {get;}
}

interface IHaveAddress {
    Address {get;}
}

class Party : Entity<int> {
    IList<IHaveAddress> _address;
}

そのようなアイデアにメリットはありますか？

乾杯、
ベリール

答え

はい、私の考えは不完全でした:-)
私が探していたオブジェクトは、以下のモデルのコンテキストでは、エンティティです。

IAbstractとこの素晴らしいリンクに感謝します

ここに画像の説明を入力してください

4

1 に答える 1

2

これは役に立ちますか：MSDNブログ...値オブジェクト基本クラスを実装しますか？私は遊ぶために何か新しいものを見つけたと思います...

更新 これがどれだけの答えであるかはわかりません
...「パーティー」ではなく、標準の「複合」用語を使用する方がはるかに混乱が少ないと思います。事実上、会社（ルート）、多くの人（または退職）が働くアドレス（またはブランチ）のセットがあります。

まだ、 ValueObjectが実際にどれだけの価値を持っているかはわかりません。表面的には、スーパータイプはAddressオブジェクトを比較するのに役立つ場合があります。とはいえ、これはやや後ろ向きな感じがするようです。そうは言っても、あなたの例では、1つのAddressオブジェクトを格納し、Personを複合オブジェクトとしてブランチAddressに追加する方が確かに理にかなっています。

前に言ったように、私はValueObjectをいくつかのCompositeオブジェクトと一緒に動作させて、その有用性を発見する個人的なプロジェクトを持っています。あなたの言及は、EntityEntity Frameworkの実装に関連していますか？または、Entity<int>単にレコードID番号を参照することを目的としていますか？

于 2011-07-05T20:42:48.740 に答える