Где размещать сообщения и регистрировать события, используя PoEAA

Question

В настоящее время у меня есть такая структура:

Domain Model <---> Data Mapper ---> Database

Скажем, я добавляю дочерний объект 'file' к объекту 'project'.Я хочу автоматически создать дочерний объект «заметка» для этого проекта, означающий обновление.Прямо сейчас создание этой заметки обрабатывается «сопоставителем файлов проекта» - в методе «uploadFile» создается и заполняется новая заметка, и вызывается «сопоставитель заметок» для сохранения этой заметки.Проект вызывает средство отображения заметок, когда его спрашивают о его дочерних заметках и т. Д. С файлами.

Или, скажем, я удаляю объект 'проекта' - я хочу также удалить дочерние заметки и файлы, поэтомуВ методе 'projectMapper' deleteProject 'вызывается как' projectNoteMapper ', так и' projectFileMapper ', чтобы обработать удаление этих файлов.

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

Я понимаю, что то, как я делаю вещи, не соответствует «принципу единой ответственности» -в конце концов, цель картографа должна состоять только в том, чтобы отображать информацию между источниками данных и их соответствующими объектами, верно?У меня вопрос: какой следующий «слой» я должен реализовать, чего мне не хватает?Я читал о «Репозитории» и «Сервисе».

Answer 1

Если бы я понял вашу проблему, то, думаю, мог бы помочь разобраться:

DataMappers не являются представлением и не соответствуют отдельной таблице в базе данных.

В случае с проектами $projectMapper->remove( $project ) имеет смысл удалить не только сам проект, но и все связанные элементы в БД.Нет ничего плохого в том, что DataMapper делает более одного запроса.Вам просто нужно реализовать соответствующую настройку для отчетов об ошибках, чтобы знать, когда / если что-то пошло не так.

И да, это также нарушает SRP в некоторых аспектах (но только если вы рассматриваете каждое изменение в БД как отдельноепричина изменения класса DataMapper).

Что касается следующего логического шага для развития уровня модели: вы найдете эту запись PoEEE релевантной.Просто имейте в виду, что Service layer - это не просто API поверх DataMappers и Domain Object.Он также содержит сервисов , которые несколько независимы от остальных модулей.Как отправитель (и) почты и аутентификация.

Также, чтобы прояснить это:

Модель - это не класс, а слой, который содержит оба объекта домена ^{[1] [2]} и DataMappers.