Страница 8 из 8
Re: Пример чистой архитектуры на оценку
Добавлено: 2019.10.08, 09:28
maleks
uEhlO4a писал(а): ↑2019.10.08, 09:17
maleks,
behavior - save() delete() getById() - это что по-твоему?
Это ход мыслей педанта.
ActiveRecord - это прежде всего доменный объект, у которого есть поведение.
А поведение - 'это не только save одной строки в БД, а доменное - такое что например при вставке нового поста он возьмет еще и RBAC разрешение добавит на редактирование этого поста. Т.е. при вставке он проявил
активность и сделал какую то работу.
Re: Пример чистой архитектуры на оценку
Добавлено: 2019.10.08, 09:48
maleks
anton_z писал(а): ↑2019.10.04, 14:41
Фух, наконец руки дошли написать
свой вариант примера.
Смотрите. Соображения по архитектуре в README.md.
Ну довольно типичный же шаблон для yii, когда ради тонкости контроллера его Transaction Script в формы улетел.
Ну может и не TS там будет если он тонкой останется надстройкой над вызовами AR методов.
Опасность вызывает попытка пихать всего в AR, юзкейсы те ж вроде как раз уровня приложения а не домена задачи.
Где бы вы например письмо стали отсылать(модератору) при добавлении нового поста? К событиям AR бы этим глобально привязывались?
Re: Пример чистой архитектуры на оценку
Добавлено: 2019.10.08, 10:18
ElisDN
uEhlO4a писал(а): ↑2019.10.08, 09:17
behavior - save() delete() getById() - это что по-твоему?
так что попробуй убрать ActiveRecord и найти решение, чтобы было по этой книжке и засунуть это в Yii2. если получтся, админ тебя в core команду заберет, инфа 100
Методы find(), save() и delete() – это как раз инфраструктура Record. Доставание и сохранение "записи" таблицы.
Active – это именно активное поведение. Пользовательские методы с бизнес-логикой.
uEhlO4a писал(а): ↑2019.10.08, 09:17
следующий твой висер я буду игнорить
Спасибо.
Re: Пример чистой архитектуры на оценку
Добавлено: 2019.10.08, 13:39
anton_z
maleks писал(а): ↑2019.10.08, 09:48
Ну может и не TS там будет если он тонкой останется надстройкой над вызовами AR методов.
Ну да, транзакции внутри методов AR. Задача формы - проверить данные и, если все нормально, передать управление дальше.
maleks писал(а): ↑2019.10.08, 09:48
Где бы вы например письмо стали отсылать(модератору) при добавлении нового поста? К событиям AR бы этим глобально привязывались?
Я обработчики событий делаю либо через статический Event::on() либо в behavior для AR. Ничего плохого ни в том ни в другом не вижу, и там и там обработчик можно протестировать отдельно. В тестах самой AR behavior с обработкой событий всегда можно отключить.
P.S в AR все подряд засовывать не надо, только то что меняет ее состояние (или состояние агрегата в целом) или вычисляет что-то на основе этого состояния и при этом не приводит к излишнему повышению связанности (каждый случай надо рассматривать индивидуально, но есть общие признаки). Дополните свой пример кейсом, где в сервисе будет бизнес-логика с зависимостью, тогда я смогу дополнить свой форк сервисом или поместить зависимость в AR (зависит от кейса), постараюсь описать правила, которыми я руководствуюсь при решении как распределить поведение между AR и сервисами.