По хорошему этот метод не должен быть в самом объекте.
Его и не будет в объекте модели. Он по сути должен быть в объекте коллекции моделей. Но реализация такого будет я думаю более чем нетривиальна, если делать ее универсальной для всех коллекций.
Ваш вариант с отдельными методами в репозиториях значительно проще в реализации, и достаточно удобен на мой взгляд.
Вопрос в том, каким способом лучше поднимать связанные данные, всё сразу или с отложенной загрузкой?
Я думаю тут должен быть во главе вопрос «зачем», а не «как». Использовать или нет ленивую загрузку (lazy loading) надо решать в каждом конкретном случае.
Например Doctrine по умолчанию использует ленивую загрузку, но позволяет загрузить все сразу когда это необходимо.
при чем последние методы работают одинаково, как для одного объекта, так и для коллекции объектов (похоже на Composite).
Не уловил мысли. Примерно так:
$post = $repository->find(1);
$comments = $post->getComments(); // комментарии к посту с id 1
$posts = $repository->findBy(['author' => 'Вася']);
$comments = $posts->getComments(); // комментарии к постам Васи
Это было бы более чем интересной функциональностью, но я подобного нигде не встречал.
Совершенно необязательно. Логика может быть в различных сервисах, а контроллер только дергает нужные. Чаще проще сделать маленький сервис с необходимыми зависимостями, чем пробрасывать зависимости в объект модели.
если использовать запись «сырых» данных, используя, например, $instance->price = 12.95
Я и не рекомендую использовать публичные свойства. Причины (понятность, дублирование) вы сами указали.
Поясню почему я против «магии» в данном варианте. Текущая реализация мешает бизнес-логику (наши модели) с технической реализацией, что чревато в дальнейшем сложноподдерживаемым кодом и трудноуловимыми ошибками. Я стараюсь оставлять модели максимально чистыми, не подверженными технической реализации. Это позволит впоследствии изменить одну часть не затрагивая другую. Например поменять одну ORM систему на другую, или вообще отказаться от ORM в угоду производительности в «узких» местах.
Это конечно только мое мнение, и оно не претендует на истину в последней инстанции.
он (программист) должен думать о логике работы приложения, а не об очередном UPDATE-запросе.
Для этого существуют ORM. Мой выбор Doctrine, но Propel также очень и очень хорош.
На мой взгляд, чтобы код легко читался, он (помимо, разумеется, стандартов кодирования и понятности алгоритмов) должен быть максимально приближен к естественному языку.
Чтобы код легко читался однозначно следует избегать использования «магических» методов. Даже не учитывая проблемы с производительностью (особенно в предложенном варианте с двумя регулярными выражениями внутри), магия усложняет чтение кода. В чем проблема написать get и set методы для нужных свойств модели? Большинство IDE позволяют это делать автоматически.
Для схожих целей использую select2. Фильтрация встроенная, но для одиночных select'ов на мой взгляд менее удобная, чем предложенный вами вариант. В закладки.
Его и не будет в объекте модели. Он по сути должен быть в объекте коллекции моделей. Но реализация такого будет я думаю более чем нетривиальна, если делать ее универсальной для всех коллекций.
Ваш вариант с отдельными методами в репозиториях значительно проще в реализации, и достаточно удобен на мой взгляд.
Я думаю тут должен быть во главе вопрос «зачем», а не «как». Использовать или нет ленивую загрузку (lazy loading) надо решать в каждом конкретном случае.
Например Doctrine по умолчанию использует ленивую загрузку, но позволяет загрузить все сразу когда это необходимо.
Не уловил мысли. Примерно так:
Это было бы более чем интересной функциональностью, но я подобного нигде не встречал.
Думаю понятно.
Вот этот момент достаточно интересен.
Я и не рекомендую использовать публичные свойства. Причины (понятность, дублирование) вы сами указали.
Поясню почему я против «магии» в данном варианте. Текущая реализация мешает бизнес-логику (наши модели) с технической реализацией, что чревато в дальнейшем сложноподдерживаемым кодом и трудноуловимыми ошибками. Я стараюсь оставлять модели максимально чистыми, не подверженными технической реализации. Это позволит впоследствии изменить одну часть не затрагивая другую. Например поменять одну ORM систему на другую, или вообще отказаться от ORM в угоду производительности в «узких» местах.
Это конечно только мое мнение, и оно не претендует на истину в последней инстанции.
Для этого существуют ORM. Мой выбор Doctrine, но Propel также очень и очень хорош.
Чтобы код легко читался однозначно следует избегать использования «магических» методов. Даже не учитывая проблемы с производительностью (особенно в предложенном варианте с двумя регулярными выражениями внутри), магия усложняет чтение кода. В чем проблема написать get и set методы для нужных свойств модели? Большинство IDE позволяют это делать автоматически.
P.S. Очень не хватает демо.