Подход к проектированию сервисных объектов должен быть конкретным или общим?

Question

Сценарий: Использование многоуровневого подхода со службами WCF: бизнес-службы возвращают клиенту объекты домена / DTO. Все еще в разработке, поэтому мы можем разорвать контракты.

Объект Person имеет имя и фамилию. Объект-член имеет налоговый номер и дату рождения. Это связано с тем, что в нашем домене только члены получают налоговые номера и даты рождения. При получении данных от службы, использующей эту структуру, ясно, какие атрибуты применимы.

Теперь мы представляем еще одну услугу, которая предназначена для использования человеком - скажем, Сотрудник. при этом объекте персоны требуются дополнительные атрибуты номер налогового файла и дата рождения.

Как лучше поступить?

1) Рассматривать объект Person как универсальный объект Person и включать все атрибуты. Это сопоставляет Человека с человеком реального мира, не обязательно основанным на использовании. Это означает, что услуги, которые возвращают лиц, будут содержать номер налогового файла и дату рождения, даже если они могут не иметь отношения.

2) Дублируйте дополнительные поля в Employee. Это оставляет Person как есть и сохраняет специфические вызовы службы за счет дублирования.

3) Создайте еще один промежуточный объект с именем PersonWithDOBTFN, от которого мы наследуем элемент и сотрудник. Это устраняет дублирование, сохраняет специфичность, но вносит сложности.

Я действительно ищу лучший подход к проектированию этих объектов.

Answer 1

Существует проблема с тем, что вы делаете, - она ​​ломается при различных обстоятельствах.Самый очевидный случай сразу из вашего краткого примера - если человек хочет быть членом и сотрудником.Как насчет того, когда человек больше не хочет быть сотрудником, а вместо этого хочет просто снова стать человеком?

Сотрудник и член не являются истинными понятиями "это".Я могу «быть» сотрудником или участником, но на самом деле это не то, чем я являюсь на самом деле, или основа моей идентичности как сущности.Участник и Сотрудник - это только две из большого числа ролей , которые мы также занимаем в качестве личности.

Не смоделируйте роль с наследованием, Это не очень хорошо работает.Вместо этого просто добавьте Person и добавьте коллекцию ролей, которая может меняться, поддерживать несколько участников одним человеком и т. Д.

Остальные, эххх.Атрибуты карты, к которым они логически принадлежат, не основаны на какой-либо политике или предыдущих действиях.Службы возвращают то, что вы хотите, чтобы они возвращали, базовая структура данных должна быть логичной и предотвращать дублирование.

Answer 2

Я бы соблазнился пойти с

Person ---is-a---> Member ---is-a--> Employee

Это предполагает, что есть нечто явно отличное в том, как работает «Сотрудник» по сравнению с «Членом». В вашем вопросе нет ничего, что указывало бы на то, что, но я предполагаю, что в Employee будут дополнительные функции, которых у Участника нет.

Что касается вашей точки зрения на сложность, я бы сказал, что на данном этапе вашего дизайна это, вероятно, то, о чем вы беспокоитесь преждевременно. 2 уровня иерархии объектов не так уж и сложны - большинство систем приличного размера обычно имеют более 2 уровней, если попытаться отделить логику. Ваша точка зрения на сложность - это то, о чем вам следует больше думать, когда ваша система развивается, и если она достигает уровней, где она становится намного сложнее, чем эта.