нет, его надо инициализировать либо прокидывать в сервис, т.е. ты не можешь взять и PDO::query('select...');Sam Dark писал(а):PDO тоже доступен отовсюду
это да.Sam Dark писал(а):как и, например, query builder.
нет, его надо инициализировать либо прокидывать в сервис, т.е. ты не можешь взять и PDO::query('select...');Sam Dark писал(а):PDO тоже доступен отовсюду
это да.Sam Dark писал(а):как и, например, query builder.
ну так да. Поэтому и говорю, что соблазн - в yii2 все наружу светит. Коннекшн сконфигурил и целый пул инструментов наружу. Кстати, интересный хак - в конфиге коннекшну задать отличный от db id компонента) все, что не предусмотрено, будет выдавать ошибку.Sam Dark писал(а):Так-то много всего доступно глобально. Из view, например, технически ничто не может запретить поработать с файловой системой средствами самого PHP. Да и откуда угодно... не только из view, который, конечно, можно ограничить введя в проект какой-нибудь Twig.
В этом плане AR не сильно отличается от встроенных функций PHP. Технически его можно юзать откуда угодно, но, как и в случае функций, надо себя ограничивать в этом стремлении.
наружу светят прикладные функции. Мало что можно причислить к бизнесу.Sam Dark писал(а):Ну с Yii, допустим, понятно. А что делать с самим PHP, который тоже наружу светит?
Ну может попробовать заполнить свои AR-агрегаты методами populate(), beforeSave() и afterSave() для трансформаций VO и каскадного сохранения связей. Для начала вполне сойдётslavcodev писал(а):И тогда не будет проблем с AR...
надеюсь это не сарказм )ElisDN писал(а):Ну может попробовать заполнить свои AR-агрегаты методами populate(), beforeSave() и afterSave() для трансформаций VO и каскадного сохранения связей. Для начала вполне сойдётslavcodev писал(а):И тогда не будет проблем с AR...
Не сарказм. Часто так делаю.Melodic писал(а):надеюсь это не сарказм )
Так сейчас и делаю (вообще не обращаюсь на прямую к property столбцам AR)
то, что это можно сделать, не значит, что систему не следует упростить, разбив на маленькие, несвязаные, хорошо тестируемые компоненты, лишеные минусов монолита.slavcodev писал(а):Используйте интерфейс ActiveRecord (populate, beforeSave(), afterSave()) для сохранения БД
Используйте интерфейс репозитория для сохранения и восстановление сущностей.
Тоже сразу об этом подумал. Много чего доступно глобально, так что это не аргумент. Не понимаю почему говорят что AR это плохо, ведь какая разница что там используется внутри репозитория ar, query builder, raw sql или что-то еще. Это никак не нарушает lose coupling из GRASP, так как для сервисов работа с хранилищем скрыта за репозиториями.Sam Dark писал(а):PDO тоже доступен отовсюду, как и, например, query builder.
Я как-то не улавливаю связи, почему пользователь должен задумываться о том, что AR нарушает SRP или что-то там еще, если это не его код и он его не поддерживает и не собирается. Какая ему разница какие принципы этот код нарушает? Он просто его берет и использует. Это тоже самое, как задумываться о том, а не нарушает ли какие-нибудь принципы код операционной системы, базы данных или любой другой, который мы используем в своих проектах. Помоему это вообще неважно, что там и как сделано. Да хоть спагетти-код, это дело разработчика этого стороннего кода, как он будет в дальнейшем поддерживать свой код, пользователю это абсолютно неважно.zelenin писал(а):ирония в том, что SRP - это единственная ответственность для класса, а AR - это куча всяких ответственностей в одном классе.
я может не совсем вас понял, ночь все таки. но если верно то вот мой ответ - как вы потом в крупном проекте щелчком пальца замените хранилище? Эти все разделения делают для того, что бы легко было любой компонент\слой заменить.sda писал(а):Тоже сразу об этом подумал. Много чего доступно глобально, так что это не аргумент. Не понимаю почему говорят что AR это плохо, ведь какая разница что там используется внутри репозитория ar, query builder, raw sql или что-то еще. Это никак не нарушает lose coupling из GRASP, так как для сервисов работа с хранилищем скрыта за репозиториями.Sam Dark писал(а):PDO тоже доступен отовсюду, как и, например, query builder.
Я как-то не улавливаю связи, почему пользователь должен задумываться о том, что AR нарушает SRP или что-то там еще, если это не его код и он его не поддерживает и не собирается. Какая ему разница какие принципы этот код нарушает? Он просто его берет и использует. Это тоже самое, как задумываться о том, а не нарушает ли какие-нибудь принципы код операционной системы, базы данных или любой другой, который мы используем в своих проектах. Помоему это вообще неважно, что там и как сделано. Да хоть спагетти-код, это дело разработчика этого стороннего кода, как он будет в дальнейшем поддерживать свой код, пользователю это абсолютно неважно.zelenin писал(а):ирония в том, что SRP - это единственная ответственность для класса, а AR - это куча всяких ответственностей в одном классе.
Ну да. Вы напишете новый класс репозитория и замените им тот, который внутри себя использовал ar. Не имеет значения, что находится внутри репозитория ar, dao, raw sql или что-то еще, поскольку бизнес-логика знает только об интерфейсе репозитория и не знает что там внутри.S c писал(а): я может не совсем вас понял, ночь все таки. но если верно то вот мой ответ - как вы потом в крупном проекте щелчком пальца замените хранилище? Эти все разделения делают для того, что бы легко было любой компонент\слой заменить.
глобально доступны функции "низкого" порядка - функции непосредственно языка. Высокие абстракции не должны глобально светить.sda писал(а):Тоже сразу об этом подумал. Много чего доступно глобально
волновать должно, что AR можно заюзать ВНЕ репозитория, и это будет сделано, т.к. типичный кейс использования AR в yii - использовать его везде. Я об этом кстати рассказываю вполне конкретно - один из форумчанинов рассказывал об опыте внедрения слоистой архитектуре в команде из трех человек: репозитории были на AR, и оба других разработчика юзали AR на прямую, потому что это привычно.sda писал(а):Не понимаю почему говорят что AR это плохо, ведь какая разница что там используется внутри репозитория ar, query builder, raw sql или что-то еще
мы тут вообще о своем коде говорим - стоит ли в своем коде использовать AR.sda писал(а):Я как-то не улавливаю связи, почему пользователь должен задумываться о том, что AR нарушает SRP или что-то там еще, если это не его код и он его не поддерживает и не собирается. Какая ему разница какие принципы этот код нарушает? Он просто его берет и использует. Это тоже самое, как задумываться о том, а не нарушает ли какие-нибудь принципы код операционной системы, базы данных или любой другой, который мы используем в своих проектах. Помоему это вообще неважно, что там и как сделано. Да хоть спагетти-код, это дело разработчика этого стороннего кода, как он будет в дальнейшем поддерживать свой код, пользователю это абсолютно неважно.
Они точно также могут использовать и любые другие компоненты уровня фреймворка напрямую включая тот же query builder. Могут самостоятельно насоздавать AR моделей и использовать их кто им запретит. Могут не пользоваться внедрением зависимостей. Могут забить на solid и grasp. Могут писать спагетти код. Могут вообще делать всё что угодно. Я считаю, что это больше к код ревью относится. Нужно просто организовать работу по github flow или как-то еще и прежде чем мержить какое-то изменение в тех же пулл риквестах команда будет иметь возможность поучаствовать в обсуждении. Просто желательно чтобы был какой-то фидбек и одобрение хотя бы от нескольких других членов команды, прежде чем смержить любое изменение. Тем более мержить должен уж никак не тот, который делает прямые вызовы к AR из бизнес-логики если все договорились этого не делать. И сразу же все эти выдуманные проблемы исчезнут.репозитории были на AR, и оба других разработчика юзали AR на прямую, потому что это привычно.
именно! Поэтому yii и не подходит для построения хорошей архитектуры. Сделать можно, но черный вход останется. Парадигма у фреймворка совершенно другая, начиная с того, что все приложение доступно глобально, что в свою очередь позволяет мало того, что не думать о di, так и позволяет даже не узнать, что такое понятие вообще есть.sda писал(а):Они точно также могут использовать и любые другие компоненты уровня фреймворка напрямую включая тот же query builder. Могут самостоятельно насоздавать AR моделей и использовать их кто им запретит.репозитории были на AR, и оба других разработчика юзали AR на прямую, потому что это привычно.
никто не будет в здравом уме создавать коннекшн к базе во вьюшке и делать с его помощью запрос. Максимум через DI получит инстанс коннекшна, т.к. глобально он не доступен, и им воспользуется. Ключевое слово DI. То есть человек уже понимает как работать с di и sl, уже начал разбираться в архитектуре приложения, и ему следует только подсказать, что вместо коннекшна нужно воспользоваться сервисом/репозиторием.S c писал(а):Ну действительно ведь, есть некие правила в каждом проекте, в том числе архитектурные (мы ж сейчас говорим о крупных проектах). Грамотные разработчики будут делать все правильно и проблем не будет, особенно если есть ревью кода. А слабые разработчики в любой архитектуре накосячат... они во view могут и чистый sql запрос выполнить, никак это не запретишь.