Сервисы и репозитории. Слоистая архитектура. Примеры.

Обсуждаем, как правильно строить приложения
zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение zelenin »

Sam Dark писал(а):PDO тоже доступен отовсюду
нет, его надо инициализировать либо прокидывать в сервис, т.е. ты не можешь взять и PDO::query('select...');
Sam Dark писал(а):как и, например, query builder.
это да.

Аватара пользователя
samdark
Администратор
Сообщения: 9365
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение samdark »

Так-то много всего доступно глобально. Из view, например, технически ничто не может запретить поработать с файловой системой средствами самого PHP. Да и откуда угодно... не только из view, который, конечно, можно ограничить введя в проект какой-нибудь Twig.

В этом плане AR не сильно отличается от встроенных функций PHP. Технически его можно юзать откуда угодно, но, как и в случае функций, надо себя ограничивать в этом стремлении.

На тему просвещения программистов — да, это проблема. Проблема общая, не только Yii.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение zelenin »

Sam Dark писал(а):Так-то много всего доступно глобально. Из view, например, технически ничто не может запретить поработать с файловой системой средствами самого PHP. Да и откуда угодно... не только из view, который, конечно, можно ограничить введя в проект какой-нибудь Twig.

В этом плане AR не сильно отличается от встроенных функций PHP. Технически его можно юзать откуда угодно, но, как и в случае функций, надо себя ограничивать в этом стремлении.
ну так да. Поэтому и говорю, что соблазн - в yii2 все наружу светит. Коннекшн сконфигурил и целый пул инструментов наружу. Кстати, интересный хак - в конфиге коннекшну задать отличный от db id компонента) все, что не предусмотрено, будет выдавать ошибку.

Аватара пользователя
samdark
Администратор
Сообщения: 9365
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение samdark »

Ну с Yii, допустим, понятно. А что делать с самим PHP, который тоже наружу светит?

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение zelenin »

Sam Dark писал(а):Ну с Yii, допустим, понятно. А что делать с самим PHP, который тоже наружу светит?
наружу светят прикладные функции. Мало что можно причислить к бизнесу.
Да, разработчик может напрямую к файлу обратиться. file_get_contents - данность. AR - нет.

Опять же речь о достаточно высокоуровневых абстракциях, который мы предоставляем разработчику. Репозитории и AR - аналоги. PDO - более низкоуровневое.

Аватара пользователя
ElisDN
Сообщения: 5606
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение ElisDN »

slavcodev писал(а):И тогда не будет проблем с AR...
Ну может попробовать заполнить свои AR-агрегаты методами populate(), beforeSave() и afterSave() для трансформаций VO и каскадного сохранения связей. Для начала вполне сойдёт :)

Melodic
Сообщения: 87
Зарегистрирован: 2016.05.11, 17:43
Откуда: Луганск

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение Melodic »

ElisDN писал(а):
slavcodev писал(а):И тогда не будет проблем с AR...
Ну может попробовать заполнить свои AR-агрегаты методами populate(), beforeSave() и afterSave() для трансформаций VO и каскадного сохранения связей. Для начала вполне сойдёт :)
надеюсь это не сарказм )

Так сейчас и делаю (вообще не обращаюсь на прямую к property столбцам AR)

Аватара пользователя
ElisDN
Сообщения: 5606
Зарегистрирован: 2012.10.07, 10:24
Контактная информация:

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение ElisDN »

Melodic писал(а):надеюсь это не сарказм )
Так сейчас и делаю (вообще не обращаюсь на прямую к property столбцам AR)
Не сарказм. Часто так делаю.

Аватара пользователя
slavcodev
Сообщения: 3134
Зарегистрирован: 2009.04.02, 21:42
Откуда: Valencia
Контактная информация:

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение slavcodev »

Используйте интерфейс ActiveRecord (populate, beforeSave(), afterSave()) для сохранения БД
Используйте интерфейс репозитория для сохранения и восстановление сущностей.
Жду Yii 3!

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение zelenin »

slavcodev писал(а):Используйте интерфейс ActiveRecord (populate, beforeSave(), afterSave()) для сохранения БД
Используйте интерфейс репозитория для сохранения и восстановление сущностей.
то, что это можно сделать, не значит, что систему не следует упростить, разбив на маленькие, несвязаные, хорошо тестируемые компоненты, лишеные минусов монолита.

sda
Сообщения: 334
Зарегистрирован: 2013.12.19, 09:29

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение sda »

Sam Dark писал(а):PDO тоже доступен отовсюду, как и, например, query builder.
Тоже сразу об этом подумал. Много чего доступно глобально, так что это не аргумент. Не понимаю почему говорят что AR это плохо, ведь какая разница что там используется внутри репозитория ar, query builder, raw sql или что-то еще. Это никак не нарушает lose coupling из GRASP, так как для сервисов работа с хранилищем скрыта за репозиториями.
zelenin писал(а):ирония в том, что SRP - это единственная ответственность для класса, а AR - это куча всяких ответственностей в одном классе.
Я как-то не улавливаю связи, почему пользователь должен задумываться о том, что AR нарушает SRP или что-то там еще, если это не его код и он его не поддерживает и не собирается. Какая ему разница какие принципы этот код нарушает? Он просто его берет и использует. Это тоже самое, как задумываться о том, а не нарушает ли какие-нибудь принципы код операционной системы, базы данных или любой другой, который мы используем в своих проектах. Помоему это вообще неважно, что там и как сделано. Да хоть спагетти-код, это дело разработчика этого стороннего кода, как он будет в дальнейшем поддерживать свой код, пользователю это абсолютно неважно.

Аватара пользователя
S c
Сообщения: 878
Зарегистрирован: 2012.04.11, 14:46

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение S c »

sda писал(а):
Sam Dark писал(а):PDO тоже доступен отовсюду, как и, например, query builder.
Тоже сразу об этом подумал. Много чего доступно глобально, так что это не аргумент. Не понимаю почему говорят что AR это плохо, ведь какая разница что там используется внутри репозитория ar, query builder, raw sql или что-то еще. Это никак не нарушает lose coupling из GRASP, так как для сервисов работа с хранилищем скрыта за репозиториями.
zelenin писал(а):ирония в том, что SRP - это единственная ответственность для класса, а AR - это куча всяких ответственностей в одном классе.
Я как-то не улавливаю связи, почему пользователь должен задумываться о том, что AR нарушает SRP или что-то там еще, если это не его код и он его не поддерживает и не собирается. Какая ему разница какие принципы этот код нарушает? Он просто его берет и использует. Это тоже самое, как задумываться о том, а не нарушает ли какие-нибудь принципы код операционной системы, базы данных или любой другой, который мы используем в своих проектах. Помоему это вообще неважно, что там и как сделано. Да хоть спагетти-код, это дело разработчика этого стороннего кода, как он будет в дальнейшем поддерживать свой код, пользователю это абсолютно неважно.
я может не совсем вас понял, ночь все таки. но если верно то вот мой ответ - как вы потом в крупном проекте щелчком пальца замените хранилище? Эти все разделения делают для того, что бы легко было любой компонент\слой заменить.

sda
Сообщения: 334
Зарегистрирован: 2013.12.19, 09:29

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение sda »

S c писал(а): я может не совсем вас понял, ночь все таки. но если верно то вот мой ответ - как вы потом в крупном проекте щелчком пальца замените хранилище? Эти все разделения делают для того, что бы легко было любой компонент\слой заменить.
Ну да. Вы напишете новый класс репозитория и замените им тот, который внутри себя использовал ar. Не имеет значения, что находится внутри репозитория ar, dao, raw sql или что-то еще, поскольку бизнес-логика знает только об интерфейсе репозитория и не знает что там внутри.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение zelenin »

sda писал(а):Тоже сразу об этом подумал. Много чего доступно глобально
глобально доступны функции "низкого" порядка - функции непосредственно языка. Высокие абстракции не должны глобально светить.
sda писал(а):Не понимаю почему говорят что AR это плохо, ведь какая разница что там используется внутри репозитория ar, query builder, raw sql или что-то еще
волновать должно, что AR можно заюзать ВНЕ репозитория, и это будет сделано, т.к. типичный кейс использования AR в yii - использовать его везде. Я об этом кстати рассказываю вполне конкретно - один из форумчанинов рассказывал об опыте внедрения слоистой архитектуре в команде из трех человек: репозитории были на AR, и оба других разработчика юзали AR на прямую, потому что это привычно.
sda писал(а):Я как-то не улавливаю связи, почему пользователь должен задумываться о том, что AR нарушает SRP или что-то там еще, если это не его код и он его не поддерживает и не собирается. Какая ему разница какие принципы этот код нарушает? Он просто его берет и использует. Это тоже самое, как задумываться о том, а не нарушает ли какие-нибудь принципы код операционной системы, базы данных или любой другой, который мы используем в своих проектах. Помоему это вообще неважно, что там и как сделано. Да хоть спагетти-код, это дело разработчика этого стороннего кода, как он будет в дальнейшем поддерживать свой код, пользователю это абсолютно неважно.
мы тут вообще о своем коде говорим - стоит ли в своем коде использовать AR.

sda
Сообщения: 334
Зарегистрирован: 2013.12.19, 09:29

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение sda »

репозитории были на AR, и оба других разработчика юзали AR на прямую, потому что это привычно.
Они точно также могут использовать и любые другие компоненты уровня фреймворка напрямую включая тот же query builder. Могут самостоятельно насоздавать AR моделей и использовать их кто им запретит. Могут не пользоваться внедрением зависимостей. Могут забить на solid и grasp. Могут писать спагетти код. Могут вообще делать всё что угодно. Я считаю, что это больше к код ревью относится. Нужно просто организовать работу по github flow или как-то еще и прежде чем мержить какое-то изменение в тех же пулл риквестах команда будет иметь возможность поучаствовать в обсуждении. Просто желательно чтобы был какой-то фидбек и одобрение хотя бы от нескольких других членов команды, прежде чем смержить любое изменение. Тем более мержить должен уж никак не тот, который делает прямые вызовы к AR из бизнес-логики если все договорились этого не делать. И сразу же все эти выдуманные проблемы исчезнут.

Если все могут делать что хотят и мержить это потихому, то это проблема воркфлоу, не AR. Мое мнение.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение zelenin »

sda писал(а):
репозитории были на AR, и оба других разработчика юзали AR на прямую, потому что это привычно.
Они точно также могут использовать и любые другие компоненты уровня фреймворка напрямую включая тот же query builder. Могут самостоятельно насоздавать AR моделей и использовать их кто им запретит.
именно! Поэтому yii и не подходит для построения хорошей архитектуры. Сделать можно, но черный вход останется. Парадигма у фреймворка совершенно другая, начиная с того, что все приложение доступно глобально, что в свою очередь позволяет мало того, что не думать о di, так и позволяет даже не узнать, что такое понятие вообще есть.

Аватара пользователя
S c
Сообщения: 878
Зарегистрирован: 2012.04.11, 14:46

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение S c »

Ну действительно ведь, есть некие правила в каждом проекте, в том числе архитектурные (мы ж сейчас говорим о крупных проектах). Грамотные разработчики будут делать все правильно и проблем не будет, особенно если есть ревью кода. А слабые разработчики в любой архитектуре накосячат... они во view могут и чистый sql запрос выполнить, никак это не запретишь.

zelenin
Сообщения: 10596
Зарегистрирован: 2013.04.20, 11:30

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение zelenin »

S c писал(а):Ну действительно ведь, есть некие правила в каждом проекте, в том числе архитектурные (мы ж сейчас говорим о крупных проектах). Грамотные разработчики будут делать все правильно и проблем не будет, особенно если есть ревью кода. А слабые разработчики в любой архитектуре накосячат... они во view могут и чистый sql запрос выполнить, никак это не запретишь.
никто не будет в здравом уме создавать коннекшн к базе во вьюшке и делать с его помощью запрос. Максимум через DI получит инстанс коннекшна, т.к. глобально он не доступен, и им воспользуется. Ключевое слово DI. То есть человек уже понимает как работать с di и sl, уже начал разбираться в архитектуре приложения, и ему следует только подсказать, что вместо коннекшна нужно воспользоваться сервисом/репозиторием.

Аватара пользователя
samdark
Администратор
Сообщения: 9365
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение samdark »

Ну ладно :) Технически ни один фреймворк ни на одном известном мне языке не может запретить сделать прямой запрос в базу будь то средствами PDO или query builder-а или ещё чего. Всегда можно инстанциировать тот или иной компонент напрямую, всегда можно полезть и достать из контейнера явно что-либо ну и т.д. Чёрный ход есть всегда и везде.

Аватара пользователя
samdark
Администратор
Сообщения: 9365
Зарегистрирован: 2009.04.02, 13:46
Откуда: Воронеж
Контактная информация:

Re: Сервисы и репозитории. Слоистая архитектура. Примеры.

Сообщение samdark »

Как буд-то из DI-конейнера явно получить коннекшн лучше, чем вытащить его из репозитория...

Закрыто