Страница 1 из 1

Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.20, 13:21
pistol
Добрый день! Поправьте, пожалуйста, если какие-то утверждения частично или полностью неверны:

1) Классы нижнего слоя не могут вызывать классы верхнего слоя (зависимость только сверху вниз). Слой верхнего уровня может зависеть от нижнего, но только через интерфейс.
2) Классы слоя могут вызывать только классы соседних слоев (как сверху, так и снизу) через интерфейс.
3) Любой слой можно заменить так, что соседние сверху и снизу ничего не заметят.
4) Порядок слоев сверху вниз: отображение, бизнес-логика, сервисы, данные.

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.20, 13:40
ElisDN
pistol писал(а): 2017.03.20, 13:21 Слой верхнего уровня может зависеть от нижнего, но только через интерфейс.
Через интерфейс зависимости, в основном, делаются только для инкапсуляции изменяемых частей.

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.20, 14:53
samdark
1) Классы нижнего слоя не могут вызывать классы верхнего слоя — верно. Про интерфейс — не совсем. Интерфейсом выступает любой public API. Интерфейс можно выделить впоследствии, если будет нужно заменять слой.
2) Нижние верхних не вызывают. См. пункт 1.
3) В идеале да. В реальности — не всегда.
4) Это как спроектируете... слоёв может быть и меньше и больше.

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.21, 00:44
pistol
Спасибо. Вот еще утверждение:

5) Верхний слой может вызывать только методы соседнего нижнего слоя, но не перепрыгивать через него. Верно?

Если да, то значит на этом слайде не слоистая архитектура, бизнес-логика отделена в отдельные классы, но не слой?
http://slides.silverfire.me/2016/pdffil ... -tips/#/21

В чем тогда преимущество вынесения в отдельные классы? Просто для удобства копипаста или это какая-то отдельная архитектура, другой принцип?

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.21, 04:32
anton_z
pistol писал(а): 2017.03.21, 00:44 Спасибо. Вот еще утверждение:

5) Верхний слой может вызывать только методы соседнего нижнего слоя, но не перепрыгивать через него. Верно?

Если да, то значит на этом слайде не слоистая архитектура, бизнес-логика отделена в отдельные классы, но не слой?
http://slides.silverfire.me/2016/pdffil ... -tips/#/21

В чем тогда преимущество вынесения в отдельные классы? Просто для удобства копипаста или это какая-то отдельная архитектура, другой принцип?
Верно - не слоистая. Никакая.
Автор запрашивает объект из БД в контроллере и удаляет его из БД в сервисе. Вынес часть логики удаления записи из бд в отдельный класс. Преимущество в том, что он сможет замокать объект класса Client и тестировать ClientDeleter настоящим модульным тестом без БД.

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

Мой вывод: пример крайне простой и скорее вырожденный, нежели показательный. Пример ради примера.

Заметил ли автор, что это потуги использовать AR в качестве сущности бизнес-логики в отрыве от БД? Да, сервисный слой это хорошо. Но автору, на мой взгляд, нужно было учитывать, что если хотим изоляции от БД - нужны репозитории, AR, соответственно, в топку. Не хотим - тестируем с БД и фикстурами. Если бы он в сервис id-шку передавал, а уже внутри AR вытаскивал, а потом удалял, это было бы по крайней мере логично.

Хотелось бы обсудить данную презентацию, она ж ведь от одного из авторов фреймворка, насколько я понял. Был бы благодарен за какие-либо комментарии.

P.S. ТС рекомендую смотреть материалы по архитектуре не привязываясь к yii. Разработчики сами неоднократно высказывались, что философия yii - дать набор инструментов в виде монолитного фреймворка, а не помочь построить хорошую архитектуру. Презентации и документация - просто демонстрация возможностей фреймворка и архитектура там не при чем. Начните с книги DDD in PHP и посмотрите тему "сервисный слой, как правильно" на этом форуме. Когда почитаете книгу, надергайте отдельных библиотек через composer и постройте простое консольное слабосвязанное приложение (учебное)). Начнете по-другому смотреть на разработку.

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.21, 16:43
samdark
5) Верхний слой может вызывать только методы соседнего нижнего слоя, но не перепрыгивать через него. Верно?
Да.
Хотелось бы обсудить данную презентацию, она ж ведь от одного из авторов фреймворка, насколько я понял. Был бы благодарен за какие-либо комментарии.
Позову сюда Дмитрия.

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.21, 17:08
SilverFire
Спасибо за вопросы.
Автор пытается достичь отделения бизнес-логики от БД путем вытаскивания объекта из БД в контроллере. а выполнения операций над ним в сервисе. а не путем создания репозиториев.
Этот пример появился после того, как мне задали вопрос "А как же использовать AR, если хранить бизнес-логику одинаково плохо что в контроллерах, что в моделях?".

Так что вы совершенно правильно поняли мысль: пример описывает вариант вынесения бизнес-логики из контроллера и модели в отдельный класс, но при этом не отказываясь от использования AR.
Мой вывод: пример крайне простой и скорее вырожденный, нежели показательный. Пример ради примера.
нужно было учитывать, что если хотим изоляции от БД - нужны репозитории, AR, соответственно, в топку. Не хотим - тестируем с БД и фикстурами.
Я соглашусь, что этот пример далёк от каноничности, но ограничение по времени доклада не позволяло даже краем зацепить тему DDD, покритиковать AR и объяснить концепцию репозиториев.

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.21, 17:12
zelenin
из слайдов:
Модель в MVC

Не один класс! Это целый доменный слой!
Содержит бизнес-логику
Содержит модели (таблиц, форм, ...)
следует уточнить: модель в MVC - в том числе доменный слой, т.к. модели форм или модели гридов - это не домен и не бизнес.

вообще обсуждать то в слайдах нечего - они не про слои и не про dip, а набор подсказок/рецептов.

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.21, 20:10
pistol
Вот еще утверждение для закрепления:

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

И еще просто туманный вопрос.

6) Существуют ли объективные критерии, которые позволяют отличить бизнес-логику от логики работы с данными? Или любая бизнес-логика - это просто манипулирование упакованными в абстракцию данными через интерфейс с понятными для любого человека названиями методов, совпадающими с именами образов в реальном мире?

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.21, 20:15
zelenin
pistol писал(а): 2017.03.21, 20:106) Существуют ли объективные критерии, которые позволяют отличить бизнес-логику от логики работы с данными? Или любая бизнес-логика - это просто манипулирование упакованными в абстракцию данными через интерфейс с понятными для любого человека названиями методов?
да, бизнес-логика - это работа с данными в терминах бизнеса (если термины человекочитаемые - это супер, но суть все-таки не в названиях методов, а в самой логике, которая в них выполняется)

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.22, 14:05
anton_z
Как вариант, можно получить тестируемый код в сервисе, наподобие упомянутого и без DDD и отделения от фреймворка/библиотек.. Для этого можно использовать паттерн TableGateway. Реализация - zend-db, например. Сущности - yii\base\/Model. Шлюзы к таблицам можно будет передавать в конструктор сервиса и использовать для построения запросов. Их можно будет мокать - соответственно код сервиса будет тестируемым. Если бы через QueryBuilder yii можно было бы делать запросы на Insert/Update/Delete, тогда можно было бы использовать его.
Паттерн TableGateway как-то подзабыт в современных фреймворках. На мой взгляд, он хорошо подходит для простых приложений и код получается тестируемым. Из минусов - сложности с JOIN.

В yii не планируется TableGateway или qb для insert/update/delete?

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.22, 19:06
samdark
5) Когда все становится слишком сложно, настает пора придумать еще один слой выше, который работает со всей этой сложностью через абстракцию, выступает простым бутылочным горлышком к сложному.
Да. Только не бутылочным горлышком, а понятным интерфейсом.

Re: Понимание принципа DIP и слоев в архитектуре

Добавлено: 2017.03.22, 19:07
samdark
В yii не планируется TableGateway или qb для insert/update/delete?
Мысли были, но распланировать не хватало времени. Если кампания нормально на Patreon пойдёт, попробую что-нить запилить. Хотите ускорить — предлагайте на GitHub в деталях.