Я неоднократно сталкивался с похожей проблемой как пользователь open source проектов.
Нужна мне какая-то функциональность. Зачем писать велосипед когда можно взять готовое. Я ищу готовое решение на GitHub и нахожу несколько проектов. Проекты крупные, популярные и на хабре их не раз упоминали. Но начинаю их изучать и пониаю что где-то реализация корявая, где-то не полная, где-то не удобные или не логичные мне архитектурные решения, где-то некорректная реализация архитектурных шаблонов, где-то мне нужно изменить поведение под мой проект, но я не могу его подменить в библиотеке потому что все захардкожено.
Вроде мелочь, а пользоваться нельзя. И PR не зделаешь, так как ломает BC и меняет архитектуру нельзя. Вот и приходится пилить свои велосипеды. А так не хочется этого делать. И не потому что это лишняя работа, а потому что, скорей всего, никто кроме меня не будет пользоваться моим решением. И не потому что оно хуже, а потому что оно не популярное.
Бывало и такое что я делаю PR, но после правок от ментейнера, он оказываются бесполезны для меня.
Правила валидации можно вынести в отдельный класс и реиспользовать столько сколько нужно. Такие валидаторы можно группировать из низкоуровневых правил в логические группы. Для этого очень хорошо подходит шаблон проектирования Спецификация.
А модификация запроса будет выполнятся через интерфейс QueryBuilder или как строки запроса?
В первом случае теряется смысл от кешированя, во втором теряется смысл от самой либы.
Я бы сказал что проблема в другом. Конструктор запросов означает что запрос может быть составлен не линейно и части запроса применятся в отдельных условиях или даже функциях и файлах.
Простейший пример это вывод списка сущностей с погинацией. Запрос по сути один, но первый будет с SELECT COUNT(*), а второй с LIMIT и OFFSET. В вашем случае похоже нужно писать запрос дважды.
Еще рекомендую почитать про спецификации из DDD или посмотреть пример реализации для Doctrine.
2) Sheduler
Это нужно для любых задач, например синхронизация данных с внешним апи раз в N часов. В кроне всегда будет одна строчка, вместо 100500. Это никак не относится к деплою.
Планировщик это по сути тот же крон, но внутри приложения. В документации к Laravel рекомендуют запускать планировщик раз в минуту. Вы не замечаете тут проблемы?
Проблема в том что приложение будет дергаться каждую минуту, хотя задачу возможно нужно выполнять раз в месяц или каждую третью неделю. И сколько в этом случае обращений к приложению будет идти в холостую?
Еще cron запускает процессы параллельно и fatal error в одной задаче никак не повлияет на другие. Возможно конечно Sheduler в Laravel как-то это учитывает, но не на столько качественно как cron.
Если бы Sheduler был полноценной заменой крона, то это былоб хорошим решением для хостингов на которых нет cron, но это никак не core функция.
Префиксы в том же месте, где и роуты (не вынося в отдельный yaml)
Префиксы нужны для группировки роутов модулей. Роуты модуля, как правило, лежат в модуле и, соответственно в глобальном роуте мы подключаем их с нужным нам префиксом, как это обычно и бывает.
Одной строкой задекларировать полный CRUDС
Аналогично в Symfony. Но нормальные проекты не ограничиваются только CRUD-ом. А когда мы говорим о DDD, то CRUD, вообще перестает быть актуальным
вязать с рантаймом (например выгрузить из БД, бред конечно, но мало ли)
Это удар по производительности и нужно разьве что для CMS. В Symfony это тоже можно сделать, но зачем?
Объявлять паттерны для плейсхолдеров для всей группы (или вообще глобально)
Пожалуй согласен. В Symfony этого нет. Объявить регекспы один раз, а не в каждом роуте может быть удобно, хотя реализация в Laravel мне не нравится. Ну и можно вообще отказатся от регекспов, так как всё равно маппинг делается на сущность.
А можно связать плейсхолдер с любой сущностью (например выбрать из БД энтити, как в симфони в контроллерах)
Это ParamConvertor, о котором я уже говорил ранее. Он удобнее чем в Laravel
А ещё раньше можно было одной строкой замаппить все роуты на паблик методы контроллера (задепрекейтили в 5.1, вроде, и вырезали в 5.3)
И правильно сделали
И самое главное у роутов есть приоритет. Аннотациями приоритет не сделать, приходится гибрид фигачить.
Приоритет определяется порядком определегия.
А зачем вообще приоритет роутингов? Если роутинги могут конфдиктовать, то у вас серьезные проблему в проекте
То есть, большое количество предустановленных компонентов в фраймворке которые будут не нужны большинству вы считаете плюсом?
Вы мне напомнили сейчас M-A-XG (нынче он http3) который хает фраймворки потому что в них нет хлебных крошек.
Фраймворк это каркас и конструктор, на который навешивается всю что необходимо в конкретном проекте и необходимость доставлять компоненты, это не то что нормально, это правильно.
Этот роутинг аналогичен именно симфонёвому, в Yii он иной, но при этом он гибче симфонёвого, но и многословнее.
А чем он гибче и многословней? Прочитал документацию. Абсолютно всё тоже самое, что и в Symfony. Только группировку в Symfony реализуется подругому, чуть более логчно, и ParamConvertor в Symfony удобнее. Поделитесь пожалуйста, чем роутинг в Laravel лучше чем в Symfony?
можно даже не писать, а использовать готовые вещи
добавляете новый адаптер (лоадер)
О чем я и говорю. Добавьте в Laravel фарша из Symfony и получите Symfony.
Почему же более мощный DI — это плохой вариант IoC?
Описанные вами примеры это хороший способ усложнить сопровождение проекта или выстрелить себе в ногу.
Получить сервис по интерфейсу
Это просто эпический ад. Интерфейсы описываю контракт, который реализует один или более классов (как правило более одного). И как же Service Locator будет резолвить разные сервисы с одним интерфейсом? Да никак. Бам. О, моя нога)))
Я сравнивал Yii 1 и Laravel 1, когда он только вышел.
Что мне сходу не понравилось в Laravel:
дурацкая файловая структура. Мне на тот момент она показалась не логичной.
работа с базой через такой же ActiveRecord что и в Yii. Принципиальных преимуществ я не увидел, особенно если сравнивать с Doctrine.
мне не понравился шаблонизатор. Не да Twig, пере php как в Yii, но это субъективное. Twig мне нравится больше.
Сейчас бегло пробежался по документации и увидел ещё проблемы:
роутинг через php. Тоже что и в Yii. В Symfony роутинг конечно тоже транслируется в php, но описываем мы его либо в yaml конфигах, либо в аннотациях.
аннотации считаю очень удобным инструментом, хоть и не всегда они к месту. В Laravel аннотаций я не увидел, возможно нужно было капнуть глубже.
переводы в Laravel описываются в php файлах как и в Yii. Удобно использовать формат xliff, для которого есть редакторы и можно отдавать переводы на сторону — переводчикам, не разработчикам. Также удобным является формат yaml, позволяющий построить иерархию сообщений.
для Doctrine есть бандл который позволяет переводить сообщения из БД
реализация IoC в Laravel мне показалась странной. В Yii не лучше.
Не берусь утверждаеть, что Laravel плохо фраймворк. Беглый обзор документации и некоторых статей не дает возможности в полной мере понять и оценить все тонкости и преимущества этого фраймворка, но первое и второе впечатление скорее негативное.
Laravel и так написан на компонентах Symfony, если в него перенести Doctrine, Twig и еще кое какие компоненты из Symfony, то от самого Laravel почти ничего не останется и логичнее сразу писать на Symfony.
В результате, я не увидел никаких преимуществ Laravel и Yii перед Symfony. Если я что-то упустил, просветите меня пожалуйста.
Работал с Zend 1, Symfony 2, Yii 1 и самописными фраймворками.
Как-то пришлось начать проект на Yii 1 после Symfony 2.
Год разработки я плакал горькими слезами (буквально).
Даже если очень захотеть, не говнокодить на Yii почти невозможно.
Смотрел Laravel. Тот же Yii вид сбоку.
Уже несколько лет я на Symfony и счастлив как ребенок.
DDD + CQRS + Specifications + ValueObject + Doctrine
Я неоднократно сталкивался с похожей проблемой как пользователь open source проектов.
Нужна мне какая-то функциональность. Зачем писать велосипед когда можно взять готовое. Я ищу готовое решение на GitHub и нахожу несколько проектов. Проекты крупные, популярные и на хабре их не раз упоминали. Но начинаю их изучать и пониаю что где-то реализация корявая, где-то не полная, где-то не удобные или не логичные мне архитектурные решения, где-то некорректная реализация архитектурных шаблонов, где-то мне нужно изменить поведение под мой проект, но я не могу его подменить в библиотеке потому что все захардкожено.
Вроде мелочь, а пользоваться нельзя. И PR не зделаешь, так как ломает BC и меняет архитектуру нельзя. Вот и приходится пилить свои велосипеды. А так не хочется этого делать. И не потому что это лишняя работа, а потому что, скорей всего, никто кроме меня не будет пользоваться моим решением. И не потому что оно хуже, а потому что оно не популярное.
Бывало и такое что я делаю PR, но после правок от ментейнера, он оказываются бесполезны для меня.
На сколько мне известно, нет возможности посмотреть статистику по доставке сообщений.
Правила валидации можно вынести в отдельный класс и реиспользовать столько сколько нужно. Такие валидаторы можно группировать из низкоуровневых правил в логические группы. Для этого очень хорошо подходит шаблон проектирования Спецификация.
В этом то и проблема что свойство создается на лету.
Классы не для того предназначены.
А что здесь нелогичного? Классическая цепочка вызовов.
$objимеет свойствоbarкоторое содержит объект со своействомbazи сеттером для него.Рекомендую почитать про Чёрный квадрат Малевича.
А модификация запроса будет выполнятся через интерфейс QueryBuilder или как строки запроса?
В первом случае теряется смысл от кешированя, во втором теряется смысл от самой либы.
Я бы сказал что проблема в другом. Конструктор запросов означает что запрос может быть составлен не линейно и части запроса применятся в отдельных условиях или даже функциях и файлах.
Простейший пример это вывод списка сущностей с погинацией. Запрос по сути один, но первый будет с
SELECT COUNT(*), а второй сLIMITиOFFSET. В вашем случае похоже нужно писать запрос дважды.Еще рекомендую почитать про спецификации из DDD или посмотреть пример реализации для Doctrine.
Стоило бы упомянуть ещё и про спецификации. С ними репозиторий будет чист как слеза младенца
Плюс, отсутствие версионного контроля и авторства изменений. Ну и контроль за бизнес логикой выходит за пределы приложения
Планировщик это по сути тот же крон, но внутри приложения. В документации к Laravel рекомендуют запускать планировщик раз в минуту. Вы не замечаете тут проблемы?
Проблема в том что приложение будет дергаться каждую минуту, хотя задачу возможно нужно выполнять раз в месяц или каждую третью неделю. И сколько в этом случае обращений к приложению будет идти в холостую?
Еще cron запускает процессы параллельно и fatal error в одной задаче никак не повлияет на другие. Возможно конечно Sheduler в Laravel как-то это учитывает, но не на столько качественно как cron.
Если бы Sheduler был полноценной заменой крона, то это былоб хорошим решением для хостингов на которых нет cron, но это никак не core функция.
Это есть из коробки. Если роут не найден — 404. Страницу 404 можно кастомизировать. Все ответы по умолчанию отдают 200
Sensio входит в стандартную поставку Symfony. Ссылку вам давали выше.
Префиксы нужны для группировки роутов модулей. Роуты модуля, как правило, лежат в модуле и, соответственно в глобальном роуте мы подключаем их с нужным нам префиксом, как это обычно и бывает.
Аналогично в Symfony. Но нормальные проекты не ограничиваются только CRUD-ом. А когда мы говорим о DDD, то CRUD, вообще перестает быть актуальным
Это удар по производительности и нужно разьве что для CMS. В Symfony это тоже можно сделать, но зачем?
Пожалуй согласен. В Symfony этого нет. Объявить регекспы один раз, а не в каждом роуте может быть удобно, хотя реализация в Laravel мне не нравится. Ну и можно вообще отказатся от регекспов, так как всё равно маппинг делается на сущность.
Это ParamConvertor, о котором я уже говорил ранее. Он удобнее чем в Laravel
И правильно сделали
То есть, большое количество предустановленных компонентов в фраймворке которые будут не нужны большинству вы считаете плюсом?
Вы мне напомнили сейчас M-A-XG (нынче он http3) который хает фраймворки потому что в них нет хлебных крошек.
Фраймворк это каркас и конструктор, на который навешивается всю что необходимо в конкретном проекте и необходимость доставлять компоненты, это не то что нормально, это правильно.
А чем он гибче и многословней? Прочитал документацию. Абсолютно всё тоже самое, что и в Symfony. Только группировку в Symfony реализуется подругому, чуть более логчно, и ParamConvertor в Symfony удобнее. Поделитесь пожалуйста, чем роутинг в Laravel лучше чем в Symfony?
Под переводами в Doctrine я имел в виду не хранение переводов в бд, а автоподстановку переводов полей сущности:
https://github.com/Atlantic18/DoctrineExtensions/blob/master/doc/translatable.md
О чем я и говорю. Добавьте в Laravel фарша из Symfony и получите Symfony.
Описанные вами примеры это хороший способ усложнить сопровождение проекта или выстрелить себе в ногу.
Это просто эпический ад. Интерфейсы описываю контракт, который реализует один или более классов (как правило более одного). И как же Service Locator будет резолвить разные сервисы с одним интерфейсом? Да никак. Бам. О, моя нога)))
Таких подробностей я не помню. Смотрел на него несколько лет назад когда он только появился на хабре.
Я сравнивал Yii 1 и Laravel 1, когда он только вышел.
Что мне сходу не понравилось в Laravel:
Сейчас бегло пробежался по документации и увидел ещё проблемы:
Не берусь утверждаеть, что Laravel плохо фраймворк. Беглый обзор документации и некоторых статей не дает возможности в полной мере понять и оценить все тонкости и преимущества этого фраймворка, но первое и второе впечатление скорее негативное.
Laravel и так написан на компонентах Symfony, если в него перенести Doctrine, Twig и еще кое какие компоненты из Symfony, то от самого Laravel почти ничего не останется и логичнее сразу писать на Symfony.
В результате, я не увидел никаких преимуществ Laravel и Yii перед Symfony. Если я что-то упустил, просветите меня пожалуйста.
Согласен. Было бы интересно посмотреть на что-то лучше Symfony)))
Работал с Zend 1, Symfony 2, Yii 1 и самописными фраймворками.
Как-то пришлось начать проект на Yii 1 после Symfony 2.
Год разработки я плакал горькими слезами (буквально).
Даже если очень захотеть, не говнокодить на Yii почти невозможно.
Смотрел Laravel. Тот же Yii вид сбоку.
Уже несколько лет я на Symfony и счастлив как ребенок.
DDD + CQRS + Specifications + ValueObject + Doctrine
Даже маленькие проекты на Symfony летают.
Правильней говорить: