Доменная модель для необязательного отношения многие-многие

Question

Допустим, я моделирую номера телефонов. У меня есть одна сущность для PhoneNumber, а другая для Person. Есть таблица ссылок, которая выражает связь (если есть) между PhoneNumber и Person. В таблице ссылок также есть поле для DisplayOrder.

При доступе к моей модели домена у меня есть несколько вариантов использования для просмотра Person.

1. Я могу смотреть на них без всякой PhoneNumber информации.
2. Я могу посмотреть на них для конкретного PhoneNumber.
3. Я могу посмотреть на них и всех их нынешних (или прошлых) PhoneNumbers.

Я пытаюсь смоделировать Person, не только для стандартных операций CRUD, но и для (не) назначения PhoneNumbers для Person. У меня проблемы с выражением отношений между ними, особенно в отношении свойства DisplayOrder. Я могу придумать несколько решений, но я не уверен, какое из них (если есть) будет лучшим.

1. A PhoneNumberPerson класс, обладающий свойством Person и PhoneNumber (наиболее близко напоминает дизайн базы данных)
2. A PhoneCarryingPerson класс, который наследуется от Person и имеет PhoneNumber имущество.
3. A PhoneNumber и / или PhoneNumbers свойство в Person (и наоборот, Person свойство в PhoneNumber)

Что было бы хорошим способом для моделирования этого, что имеет смысл с точки зрения модели предметной области? Как избежать неуместных свойств (DisplayOrder на Person) или условно заполненных свойств?

Answer 1

Вариант 1 имеет наибольшее количество преимуществ, так как это отношение многих ко многим. У каждого человека будет список объектов PhoneNumberPerson, а у каждого номера телефона будет список объектов PhoneNumberPerson, эффективно создающих два отношения один ко многим.

Управление отношениями один-ко-многим в долгосрочной перспективе окажется проще.

Человек без телефона будет лицом, чей список PhoneNumberPerson пуст. Вариант наследования выглядит сложным для поддержки.

Кроме того, класс PhoneNumberPerson может содержать такую ​​информацию, как дата, когда человек начал пользоваться телефоном и прекратил пользоваться телефоном, чтобы можно было легко определить, является ли он текущим телефоном.

Answer 2

Сделать Join-Table отдельным классом, например PersonalPhoneNumber

• PersonalPhoneNumber имеет два поля: один человек и один номер телефона
• У человека есть список (java.util.List) из PersonalPhoneNumber s
• порядок списка - это то, что вы хотели выразить как DisplayOrder
• PhoneNumber также может иметь набор Персоны

Answer 3

Что было бы хорошим способом смоделировать это это имеет смысл из доменной модели перспектива?

Ваш третий вариант звучит лучше всего благодаря своей простоте:

Person.PhoneNumbers // a list of phone numbers
PhoneNumber.Person  // references its parent

Как мне избежать неуместного свойства (DisplayOrder on Person) или условно заселенные объекты?

Является ли DisplayOrder произвольным или в него встроен какой-либо домен, например, дата его замены новым номером телефона? Если так, я бы изменил атрибут, чтобы он выражал это значение. То есть не храните порядок отображения в вашей базе данных, сохраняйте информацию, необходимую для построения правильного порядка отображения, и пусть ваши представления упорядочивают их, возможно, используя стратегию, определенную в модели вашего домена. (Например, StandardDisplayOrderStrategy может показывать 1) домашние номера, 2) рабочие номера, затем 3) мобильные номера.)

Что касается условно заполненных свойств, рассмотрите возможность их заполнения все время.