Как раз о проблемах своей неправильной реализации я и рассказывал. По поводу примера:
$user = $userFinder->asArray()->one(123)
Если это не всевдо-код, то если пользователь подтянет парочку реляций за собой, особенно вложенных, то мы на массивах далеко не уедем. Поэтому нужны сущности. А там еще нужно обработчики для этих сущностей и пошло поехало, а сути уже есть Doctrine.
Вся загвоздка в том, чтобы четко разделить сушьность, репозиторий и прослойку получения данных.
Тоесть Вы по сути пишите свою мини доктрину для Yii2?
Как должно быть, это одно. А как на самом деле — это совсем другое. Тоесть я имею ввиду сейчас понятие «модель» в контексте AR. Честно говоря, я еще не видел кода на Yii2 или Laravel5, которые бы использовали четкие разграничения или беспокоились об инкапсуляции данных.
И тут скорее я подвожу к проблеме того, что формат данных может меняться. С модели AR на массив или коллекцию. А вы по сути имеете ввиду сущность. Так как модель AR построена на «магии» (Магические методы в php).
А что, если кастомный запрос заджоинит дополнительные поля, которых ранее не было или наоборот, уберет ненужные поля?
Или источник данных поменяется на стороннее апи и понятие «активная запись» будет не актуально?
Вопрос, по поводу ValueObject и DTO. Я не имел еще дело на практике с данными парадигмами, а скорее вскользь просматривал литературу.
Не совсем понимаю, даже по описанию, что такое ValueObject? И как использовать DTO совместно с реляциями.
Не могли бы Вы объяснить на примере про ValueObject, минуя стандартное объяснение из книг про объект Money?
А что касается DTO, как быть в случае если есть вот такие данные:
Товар (данные товара)
— реляция на переводы
— реляция на картинки
— реляция на переводы (seo: alt, title)
— реляция на свойства
— реляция на значения
— реляция на дополнительные особенности
— реляция на ассортимент
Тоесть тут получается для каждой реляционной сущности должен быть свой DTO и обработчик, который рекурсивно (или как-то по другому) все это дело завернет?
Какая проблема в том, что бы не использовать Eloquent в Laravel, а юзать тот же Doctrine?
Да, я об этом и говорю. То есть в статье упоминаю о том, что не нужно строить свои инфраструктуры и использовать Doctrine или что-то подобное. И опять таки, Вы должны четко понимать, нужна ли вас Doctrine или дополнительный слой абстракции.
Что вообще за сущность с геттерами и сеттерами без логики? Как раз такой сущность быть не должна.
«На самом деле это был яркий пример того, когда умных книг не прочитали, а просто краем уха где-то услышали. В любой умной книге будет черным по белому написано, что реализация таких методов, как create — никак не задача репозитория. „
Невнимательность, отсутствие практики и опыта делают свое дело.
С старался в моделях держать только реляции и скоупы. Вопрос в том, что я понятия не имею как модели использовали другие разработчики. Проект писался около года, и пережил около 5 разработчиков. Что, где, куда, как и кто вызывал не ясно.
Основной целью моей статьи было показать, что не всегда правильное понятие и особенно реализацию находят паттернам проектирования. И я это сам на себе и проверил.
Кстате, для расширения кругозора я покопал symfony3, там работа с данными мне понравилась куда больше. Однако там гоняются сущности, которые вообще не завязаны на фреймворк. Хоть кода там куда больше, но выходит весьма гибко и красивее с ориентиром на будущее.
Опять таки да, это удобно, возможно даже оправданно, но это не есть реализация самого паттерна Repository, так-как Вы все-равно завязаны на моделях.
Так-как если я поменяю источник данных для получения юзеров, например из соц. сети, и даже если умышленно сделаю активную запись из данных, то $user->save() уже будет работать не очевидно. А в проектах с большой кодовой базой и несколькими разработчиками, Вы просто не будете знать, кто и что, и куда «позасовывал».
А если у Вас еще нет тестов, то тут провал. Будете в ручную тестировать весь проект.
" О том, какими должны быть хорошие модели, нужно говорить отдельно."
Скорее всего вы имеете ввиду Entity? Как я уже упоминал понятие «модель», в 99% подразумевается как класс. А это может быть доменная модель или как в DDD domain model и состоять из сотни классов.
Было-бы здорово, если бы Вы показали примеры тех «моделей», которые имеете ввиду.
Тут скорее вся суть в том, что Repository подразумевает абстракцию, тоесть не важно модель, не модель, массив не массив, нужен единый формат возврата, чтобы можно было менять источники данных. Работая с моделью по большому счету вы привязываетесь к контексту АР, тоесть абстракция уже не совсем абстракция.
«Получается как бы Read-only Repository :) По сути, просто разделение классов для обеспечения SRP. » — да, согласен. И при этом это уже получается не совсем Repository, а скорее просто чуть-более удобное разделение.
Ну тут холиварный вопрос. Я много раз убеждался, что многим технологиям и подходам есть место, главное понимать как их «готовить» и для чего они. Просто AR — это raw-разработка (чтобы было просто и легко).
Да возможно, но вы построите поверх солидный такой слой абстракции и вопрос «зачем» весьма актуален.
Хотя в целях эксперимента и обучения было бы интересно, но по факту в коммерческих проектах скорее-всего лучше так не делать.
Речь скорее о подходах как laravel5, так и Yii2, в этих инструментах сидит ActiveRecord, за несколько лет работы с ним, у меня почему-то начинает вырабатываться дикая аллергия на него. Так-как по большей части в сообществах принято считать, что модель == 1 файл (а точнее класс унаследованный от ActiveRecord).
Но если чуть-чуть покапать, поделать проекты с более сложной логикой и с весьма длительной поддержкой, то ActiveRecord породит достаточно много проблем.
Я прошел и до сих пор прохожу через множество адских штук, которые были рождены именно благодаря ActiveRecord. Это скорее претензия не к вам конкретно, а наверно для множество новичков или людей, которые порождают божественные классы, дублируют логику, суют ее во вьюшки и еще очень много интересных вещей делают.
Я не могу сказать, что я стал хорошо разбираться в этом всем деле, так как еще до сих пор обжигаюсь, но то, что мне достается из легаси кода на инструментах с использованием ActiveRecord оставляет желать лучшего.
Вообще изначально под моделью подразумевается бизнес логика по хорошему состоящая из множество различных классов, что улучшает читабельность кода, поддержку и в целом благоприятно влияет на проект. Хорошим примером будет domain model, при чем не обязательно в контексте DDD.
Я так-же согласен, что ActiveRecord это дико удобная штука, с ее помощью можно весьма быстро и удобно работать, очень просто делать реляции, различные связи и сократить код. Однако это удобство несет в себе весьма скрытую опасность, и если вам нужна длительная поддержка, жирная бизнес-логика, удобство и гибкость, то с ActiveRecord будет весьма сложно и сложнота будет стремиться к невозможному.
И самый больный пример из своего опыта, который я могу примести это примерно следующая ситуация:
Представьте, что вы работаете в небольшой конторе по разработке WEB-проектов различной сложности. Штат предположим из 5 бэкендеров в вашем подчинении. 3 из них джуны, 1 что-то похожий на мидла и вы тоже мидл, такой себе среднячковый (это я возможно о себе). Вы распределяете работу, пишите задачи, сроки горят, туда сюда, быстрее и вот потом когда вы смотрите на код работающего проекта, то все правки и доработки туда вносятся начиная с комментария «Отче наш, сущий на небесах ...».
Конечно это не проблема Yii2 или Laravel5, или вообще AR. Но сложилось как сложилось и глубокая связанность, а особенно размазанная логика весьма сложно исправляется.
В доменной же моделе, когда все разбито на отдельные части, при готовой архитектуре, которую можно навязать тем-же джунам, будет все более менее терпимо, а при желании можно подменить через тот-же DI.
Честно говоря у меня много наболело по этому поводу. Поэтому я наверно извинюсь, за излишки.
Да, но тут удобно еще. что Laravel5 сам все инжектит и проделывает. Плюс я после Yii2 достаточно быстро привык к тому, что в Laravel5 все разбили очень жестко. Это весьма удобно, в Yii2 вы как-то все соединили очень жестко. Тоесть то, что по факту можно расписать в 5 классов, влазит в одну модель.
Seeds — fixtures. Да, я когда-то сталкивался, но поработать не довелось. Засовывал данные в миграции.
Согласен с Composers, но можно придерживаться неких правил именования например: $composerMyVar.
Тоесть все переменные, которые начинаются с composer будут приходить именно от туда, очевидно, понятно и сложнее перетереть.
https://laravel.com/docs/5.3/requests
По сути в 2 словах, я могу гарантировать, что в контроллере будут уже валидные данные. Вот кстате не большой пример https://mattstauffer.co/blog/laravel-5.0-form-requests.
«Факт. Хотя даже у REST API исключительно под телефоны есть лендинг...», он может быть сделан на другой платформе или с помощью angular2 и тп.
Если это не всевдо-код, то если пользователь подтянет парочку реляций за собой, особенно вложенных, то мы на массивах далеко не уедем. Поэтому нужны сущности. А там еще нужно обработчики для этих сущностей и пошло поехало, а сути уже есть Doctrine.
Тоесть Вы по сути пишите свою мини доктрину для Yii2?
И тут скорее я подвожу к проблеме того, что формат данных может меняться. С модели AR на массив или коллекцию. А вы по сути имеете ввиду сущность. Так как модель AR построена на «магии» (Магические методы в php).
Или источник данных поменяется на стороннее апи и понятие «активная запись» будет не актуально?
Не совсем понимаю, даже по описанию, что такое ValueObject? И как использовать DTO совместно с реляциями.
Не могли бы Вы объяснить на примере про ValueObject, минуя стандартное объяснение из книг про объект Money?
А что касается DTO, как быть в случае если есть вот такие данные:
Товар (данные товара)
— реляция на переводы
— реляция на картинки
— реляция на переводы (seo: alt, title)
— реляция на свойства
— реляция на значения
— реляция на дополнительные особенности
— реляция на ассортимент
Тоесть тут получается для каждой реляционной сущности должен быть свой DTO и обработчик, который рекурсивно (или как-то по другому) все это дело завернет?
Да, я об этом и говорю. То есть в статье упоминаю о том, что не нужно строить свои инфраструктуры и использовать Doctrine или что-то подобное. И опять таки, Вы должны четко понимать, нужна ли вас Doctrine или дополнительный слой абстракции.
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/working-with-objects.html#entity-object-graph-traversal
«На самом деле это был яркий пример того, когда умных книг не прочитали, а просто краем уха где-то услышали. В любой умной книге будет черным по белому написано, что реализация таких методов, как create — никак не задача репозитория. „
Невнимательность, отсутствие практики и опыта делают свое дело.
Основной целью моей статьи было показать, что не всегда правильное понятие и особенно реализацию находят паттернам проектирования. И я это сам на себе и проверил.
«Хорошая архитектура — это дорого, Плохая — еще дороже».
Так-как если я поменяю источник данных для получения юзеров, например из соц. сети, и даже если умышленно сделаю активную запись из данных, то $user->save() уже будет работать не очевидно. А в проектах с большой кодовой базой и несколькими разработчиками, Вы просто не будете знать, кто и что, и куда «позасовывал».
А если у Вас еще нет тестов, то тут провал. Будете в ручную тестировать весь проект.
Скорее всего вы имеете ввиду Entity? Как я уже упоминал понятие «модель», в 99% подразумевается как класс. А это может быть доменная модель или как в DDD domain model и состоять из сотни классов.
Было-бы здорово, если бы Вы показали примеры тех «моделей», которые имеете ввиду.
Для «бложека» AR будет адекватным выбором, для «сделайте как вконтакте. только лучше...» скорее всего не подойдет.
Видите, я это проверил на своем горьком опыте.
«Получается как бы Read-only Repository :) По сути, просто разделение классов для обеспечения SRP. » — да, согласен. И при этом это уже получается не совсем Repository, а скорее просто чуть-более удобное разделение.
Да возможно, но вы построите поверх солидный такой слой абстракции и вопрос «зачем» весьма актуален.
Хотя в целях эксперимента и обучения было бы интересно, но по факту в коммерческих проектах скорее-всего лучше так не делать.
Но если чуть-чуть покапать, поделать проекты с более сложной логикой и с весьма длительной поддержкой, то ActiveRecord породит достаточно много проблем.
Я прошел и до сих пор прохожу через множество адских штук, которые были рождены именно благодаря ActiveRecord. Это скорее претензия не к вам конкретно, а наверно для множество новичков или людей, которые порождают божественные классы, дублируют логику, суют ее во вьюшки и еще очень много интересных вещей делают.
Я не могу сказать, что я стал хорошо разбираться в этом всем деле, так как еще до сих пор обжигаюсь, но то, что мне достается из легаси кода на инструментах с использованием ActiveRecord оставляет желать лучшего.
Вообще изначально под моделью подразумевается бизнес логика по хорошему состоящая из множество различных классов, что улучшает читабельность кода, поддержку и в целом благоприятно влияет на проект. Хорошим примером будет domain model, при чем не обязательно в контексте DDD.
Я так-же согласен, что ActiveRecord это дико удобная штука, с ее помощью можно весьма быстро и удобно работать, очень просто делать реляции, различные связи и сократить код. Однако это удобство несет в себе весьма скрытую опасность, и если вам нужна длительная поддержка, жирная бизнес-логика, удобство и гибкость, то с ActiveRecord будет весьма сложно и сложнота будет стремиться к невозможному.
И самый больный пример из своего опыта, который я могу примести это примерно следующая ситуация:
Представьте, что вы работаете в небольшой конторе по разработке WEB-проектов различной сложности. Штат предположим из 5 бэкендеров в вашем подчинении. 3 из них джуны, 1 что-то похожий на мидла и вы тоже мидл, такой себе среднячковый (это я возможно о себе). Вы распределяете работу, пишите задачи, сроки горят, туда сюда, быстрее и вот потом когда вы смотрите на код работающего проекта, то все правки и доработки туда вносятся начиная с комментария «Отче наш, сущий на небесах ...».
Конечно это не проблема Yii2 или Laravel5, или вообще AR. Но сложилось как сложилось и глубокая связанность, а особенно размазанная логика весьма сложно исправляется.
В доменной же моделе, когда все разбито на отдельные части, при готовой архитектуре, которую можно навязать тем-же джунам, будет все более менее терпимо, а при желании можно подменить через тот-же DI.
Честно говоря у меня много наболело по этому поводу. Поэтому я наверно извинюсь, за излишки.
Согласен с Composers, но можно придерживаться неких правил именования например: $composerMyVar.
Тоесть все переменные, которые начинаются с composer будут приходить именно от туда, очевидно, понятно и сложнее перетереть.
https://laravel.com/docs/5.3/requests
По сути в 2 словах, я могу гарантировать, что в контроллере будут уже валидные данные. Вот кстате не большой пример https://mattstauffer.co/blog/laravel-5.0-form-requests.
«Факт. Хотя даже у REST API исключительно под телефоны есть лендинг...», он может быть сделан на другой платформе или с помощью angular2 и тп.