混合价值对象/实体类型？

Question

是的，我同意这个标题表明我目前的思路是有缺陷的。但是为了再次达到理智，我就是这样对待这个令人遗憾的状态。

主题对象是地址，主题应用程序在三个地区办事处拥有数百名员工。在这种情况下，将（3）地址视为实体对象是有用的，并且只在数据库中保留这三个地址。

当然，员工有工作因为应用服务了数千名客户。在此上下文中，将Address视为ValueObject更为有用。

现在我希望有一个Party模式来维护公司和人们拥有的共同特征，比如......地址。

最后一个factoid - 我们有一个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;
}

这样的想法是否有任何的优点？

干杯，
Berryl

ANSWER

是的，我的想法有缺陷:-)
我正在寻找的对象是一个实体，在下面的模型中。

感谢IAbstract和this wonderful link

Answer 1

这有用吗：MSDN blogs ... Implementinag a Value-Object Base Class？我想我发现了一些新东西......

更新 我不确定这是多少答案
......我认为使用标准的“复合”术语而不是“派对”并不那么令人困惑。实际上，您有一个公司（根），一组地址（或分支），许多人（或离开）工作。

我还不确定，ValueObject实际上有多少 value 。从表面上看，超类型可能对比较地址对象非常有用。不过，这似乎有点倒退的感觉。也就是说，在您的示例中，存储1个Address对象并将Person作为复合对象添加到分支Address当然更有意义。

就像我之前说过的，我有一个个人项目，我将把ValueObject与一些Composite对象一起使用，以发现它的用处。您是否引用了与实体框架的任何实现相关的Entity？或Entity<int>仅用于引用记录ID号？