Yes, I agree the title suggests my current line of thinking is defective. BUT in the hopes of again arriving at sanity, here's how I got to this sorry state.

The subject object is an Address, and the subject application has hundreds of Employees in three regional offices. In this context, it is useful to treat the (3) addresses as Entity objects, and keep only those three Addresses in the database.

OF course the Employees have employment because the application services thousands of Customers. In this context, it is more useful to treat the Address as a ValueObject.

Now I'd like to have a Party pattern to make the maintenance of common traits that Companies and People have, like...Addresses.

Last factoid开发者_开发知识库 - we have a ValueObject class that does things you might expect from value objects (ie, determine equality based on public properties) and an Entity class (equality based on some id if the object is persistent).

So, what to do? I was playing with the following class ideas before I thought I'd ask this and see what kind of answers came back...

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;
}

Is there any merit to such an idea??

Cheers,

Berryl

ANSWER

Yes, my thinking was defective :-)

The object I was looking for is an Entity, in the context of the model below.

Thanks to IAbstract and this wonderful link

---

Does this help: MSDN blogs ... Implementinag a Value-Object Base Class? I think I've found something new to play with ...

Update I'm not sure how much of an answer this is
...I think it is much less confusing to stay with the standard 'Composite' terminology rather than 'Party'. Effectively you have a Company (root), a set of Addresses (or branches) at which many People (or leaves) work.

I'm not sure, yet, just how much value the ValueObject actually has. On the surface, the supertype may well prove useful to compare Address objects. This seems to have a somewhat backwards feel to it, though. That said, it certainly makes more sense in your example to store 1 Address object and add Person as composite objects to the branch Address.

Like I said earlier, I have a personal project in which I will put the ValueObject to work along with some Composite objects to discover it's usefulness. Is your reference to an Entity related to any implementation of Entity Framework? Or is Entity<int> simply intended to reference a record ID number?