Отношение между классами

Question

У меня есть четыре класса:

• Employee - содержит только поля, владения сведения о конкретном работнике

• EmployeeGroup - содержит только поля , которые описывают тип работника рабочих мест могут do, каждый сотрудник принадлежит к одному классов EmployeeGroup.

• EmployeeDBase - содержит методы для Добавление или получение сотрудника и Employee Group из базы данных.

• EmployeeForm - использует методы EmployeeDbase для . Получайте или добавляйте поля Employee или EmployeeGroup в базу данных. У него также есть собственные методы отображения информации в форме.

Я думаю, что отношения между Работником и EmplyeeGroup является агрегирования и между EmplyeeForm и EmployeeDBase зависимостях. Есть ли какие-либо отношения Employee и EmployeeForm, Employee и EmplyeeDBase (потому что оба работают с объектами Employee) .---

Answer 1

Ваш вопрос звучит немного ... теоретически. Почти как домашнее задание.

Для чего это стоит, я думаю, что вы не должны путать Employee & Классы EmployeeGroup - это четкие представления об объектах реального мира и EmployeeDBase и EmployeeForm, которые являются программными артефактами, внутренними для вашего приложения.

Answer 2

В целом согласен с @Benjol. Здесь есть два разных вида отношений. Employee < -> EmployeeGroup - это «доменное» отношение, то есть отражает правила и характеристики проблемного пространства. Поэтому наиболее уместно моделировать как стандартную ассоциацию - много: 1, если сотрудник может быть членом только одной группы, многие: многие в противном случае. Честно говоря, я бы не повесил трубку на агрегацию. Мощность важнее.

Другие отношения являются архитектурными, а не предметными. Я хотел бы сделать это отдельно - предпочтительно ссылкой на один или несколько архитектурных шаблонов. Взгляните на Martin Fowler's catalogue.

Наконец, два наблюдения:

1. Из вашего описания это выглядит как дизайн имеет Employee & EmployeeGroup как простые объекты стоимости со всей бизнес-логикой в ​​EmployeeForm и EmployeeDBase. Я вообще подозрительно отношусь к логике домена из классов домена. Бывают случаи, когда это оправданно - обычно для действительно простых/быстрых хакерских систем. Все, что имеет какую-либо значительную логику домена, и/или, как ожидается, будет иметь нетривиальный срок службы, обычно легче поддерживать, если логика домена лучше инкапсулирована классами домена, а не связана с уровнями ui или db. (см. «Проект, управляемый доменом» Эрика Эванса).
2. «EmployeeGroup» не является самым информативным именем. Из вашего описания было бы лучше назвать «EmployeeRole» или что-то подобное. Похоже, что это определено в книге, но не то, что вы могли бы изменить.