Domain model for an optional many-many relationship
Let's say I'm modeling phone numbers. I have one entity for PhoneNumber
, and one for Person
. There's a link table that expresses the link (if any) between the PhoneNumber
and Person
. The link table also has a field for DisplayOrder
.
When accessing my domain model, I have several Use Cases for viewing a Person
.
- I can look at them without any
PhoneNumber
information. - I can look at them for a specific
PhoneNumber
. - I can look at them and all of their current (or past)
PhoneNumbers
.
I'm trying to model Person
, not 开发者_JS百科only for the standard CRUD operations, but for the (un)assignment of PhoneNumbers
to a Person
. I'm having trouble expressing the relationship between the two, especially with respects to the DisplayOrder
property. I can think of several solutions but I'm not sure of which (if any) would be best.
- A
PhoneNumberPerson
class that has aPerson
andPhoneNumber
property (most closely resembles database design) - A
PhoneCarryingPerson
class that inherits fromPerson
and has aPhoneNumber
property. - A
PhoneNumber
and/orPhoneNumbers
property onPerson
(and vis-a-versa, aPerson
property onPhoneNumber
)
What would be a good way to model this that makes sense from a domain model perspective? How do I avoid misplaced properties (DisplayOrder
on Person
) or conditionally populated properties?
Option 1 has the most advantages since this is a many to many relationship. Each person will have a list of PhoneNumberPerson objects and each Phone Number will have a list of PhoneNumberPerson objetcs effectively creating two one to many relationships.
Managing the two one to many relationships will prove easier in the long run.
A person with no phone will then be a person whose PhoneNumberPerson list is empty. The inheritance option looks like a difficult one to maintain.
Additionally the PhoneNumberPerson class can carry information like the date that the person started using the phone and stopped using the phone so that it is easy to tell if it is a current phone or not.
What would be a good way to model this that makes sense from a domain model perspective?
Your third option sounds the best, by virtue of its simplicity:
Person.PhoneNumbers // a list of phone numbers
PhoneNumber.Person // references its parent
How do I avoid misplaced properties (DisplayOrder on Person) or conditionally populated properties?
Is DisplayOrder
arbitrary, or is there some domain meaning embedded in it, such as the date it was replaced by a new phone number? If so, I'd change the attribute so it expresses that meaning. That is, don't store the display order in your database, store the information you need to construct the correct display order and let your views order them, perhaps using a strategy defined in your domain model. (For example, a StandardDisplayOrderStrategy might show 1) home numbers, 2) work numbers, then 3) mobile numbers.)
As for conditionally populated properties, consider populating them all, all the time.
Make the Join-Table a separate class, e.g. PersonalPhoneNumber:
- PersonalPhoneNumber has two fields: One Person and one PhoneNumber
- Person has a list (java.util.List) of PersonalPhoneNumbers
- the ordering of the list is what you wanted to express as DisplayOrder
- PhoneNumber can also have a set of Persons
精彩评论