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
