Должен ли я создавать значения по умолчанию для объекта домена на моем сервисном уровне?

Я создаю приложение MVC с Zend Framework. Модель включает в себя отдельные слои домена и картографа, а слой службы находится сверху.

Для некоторых из моих объектов домена, когда я создаю новый экземпляр, мне нужно создать другие объекты домена, которые состоят из первого объекта. Например, когда я создаю новый объект «Организация», я могу добавить объект «Сотрудник» (на основе текущего пользователя) и объект «Местоположение» (на основе местоположения текущего пользователя).

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

Я бы предпочел создать дочерние элементы на уровне службы, но не навлеку ли я на себя неприятности, если сделаю это?

Прочитав главу Мартина Фаулерса (POEAA) об уровне обслуживания, я думаю, что все сводится к тому, является ли это логикой предметной области или логикой приложения/рабочего процесса. Мне кажется, что это погранично... (Обратите внимание, что мой сервисный слой уже больше, чем просто фасад).


php oop design-patterns service-layer
person DatsunBing    schedule 11.02.2013    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Насколько я понимаю из вашего описания, в настоящее время и Employee, и Location являются обязательными зависимостями для каждого экземпляра Organization. Когда вы создаете эти зависимости в конструкторе, вы создаете здесь две проблемы (это как два конца одной уродливой палки):

  • Класс Organization становится тесно связанным с именами «Сотрудник» и «Местоположение».

  • Становится очень сложно тестировать поведение экземпляров Organization, потому что у вас нет прямого контроля над его зависимостями. Вы не можете изолировать "тестируемый модуль".

Примечание A: на самом деле организации требуется набор сотрудников/членов, минимум один. В этом случае коллекция объектов домена кажется лучшим выбором с точки зрения битовых аспектов логики и реализации API.

Чтобы избежать этих проблем, есть два решения для ситуации, когда вам нужно создать сложный граф объектов:

  1. Используйте фабрику (дополненную правильно реализованным DIC), которая создает все требования вашего класса Organization и вводит их, когда вы создаете новый экземпляр.

  2. Создайте все зависимости, а затем вставьте их вручную в Organization при создании экземпляра объекта.

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

Выбор будет зависеть от того, что еще вы хотите сделать с экземплярами Employee EmployeeCollection и Location в этом и подобных случаях, и от того, какой стиль вы предпочитаете.

Если вы делаете обширные и очень специфические манипуляции с этими зависимостями, то их обязательно нужно инстанцировать отдельно (через простую фабрику объектов предметной области) и только потом внедрять. Если вы создаете только граф объектов, фабрика на основе DIC будет подходящим решением.

PS: я бы порекомендовал вам посмотреть Чистый код Беседы - Не ищите вещи! лекция.

person tereško    schedule 12.02.2013
comment
Спасибо, Тереско, как всегда очень подробный ответ! - person DatsunBing; 13.02.2013