Загрузка необходимых зависимостей через composer require symfony/bundle
Регистрация бандла в app/AppKernel.php
Регистрация маршрутов, которые предоставляет наш новый бандл, если таковые имеются
Регистрация необходимых настроек для бандла в app/config/config.yml
Реализовал в своем проекте пункты 2, 3, 4 несколько лет назад (кажется году эдак в 2013). На основе этого функционала сделал систему плагинов в приложении, а потом еще добавил систему обновлений (self-update).
И сводилось все действительно к одно команде:
composer require vendor/depdency
Планировал написать об этом статью на хабре, но руки так и не дошли.
Попробовал реализацию через рефлексию. Оказалось действительно в чем-то удобнее. Спасибо что просветили.
Проблему с человеческим описанием в myclabs/php-enum можно решить так:
final class Action extends Enum
{
const VIEW = 'view';
const EDIT = 'edit';
// можно использовать для radio/checkbox/select
public static function choices()
{
$choices = [];
foreach (self::values() as $value) {
$choices[$value->getValue()] = (string) $value;
}
return $choices;
}
public function __toString()
{
return 'acme.demo.action.'.strtolower($this->getKey());
}
}
Но вот решил я сравнить производительность реализации через рефлексию и с явным описанием вариантов значений и получилось что рефлексия в 3-4 раза медленнее в зависимости от версии php.
$ php tests/benchmark.php 100000
Reflection enum: 1.25 MiB - 14079 ms
Reflection enum no magic: 1.25 MiB - 11286 ms
Explicit enum: 1.25 MiB - 3221 ms
Тест no magic это тест без использования магических функций __call() и __callStatic() и даже он оказывается медленнее в 3 раза.
Отсюда делаем вывод. За удобство нужно платить.
Я бы посоветовал, прежде чем делать большой PR, сначала обсудить его в issues с мейнтейнером. Это поможет избавиться от лишней работы и предвидеть правки PR. Хотя по моему опыту на PR мейнтейнеры реагируют активнее.
Никакой информации о классе (родители, интерфейсы, трейты).
Никакой информации о интерфейсе класса (методы публичные и приватные).
Никакой информации о доступе к свойствам класса. Свойства есть, но не известно публичные они или приватные и если приватные, то как их получить.
Особенно эта проблема ощущается когда проваливаешься по иерархии на 2, 3, 4 и тд уровни.
Один из главных минусов xdebug — медленный и забивает диск логами профыйлинга, если явно не указать писать лог в один файл. Что не скажешь о либе которую я привел.
Настраивать профайлинг для Web и CLI сложнее чем для либы которую я упомянул (одна строчка в конфиге и все).
Не скажу что xdebug плох. Просто мне лично он на подходит. Хотя бы потому что медленный.
Уже несколько лет пользуюсь вот этой либой для отладки кода. Удобный аналог var_dump. Гараздо более читаемый и юзабельный. Рендер под web и в cli. Удобное отображение ошибок. Удобней чем в xdebug.
А что мешает написать свое решение и просто выложить его?
@springimport я в результате так и делаю. Как я и сказал, пишу свой велосипеде и выкладываю его на GitHub. Но это не совсем правильно, о чем я уже написал.
Что хорошего в том что каждый будет писать свою реализацию функциональности и постить ее на GitHub?
Просто для примера, список реализаций CQRS на PHP.
Я просмотрел около 20 проектов из списка, не найдя удобно мне сделал свою реализацию и думаю выложить её на GitHub. Хорошо ли это? Не уверен.
Я неоднократно сталкивался с похожей проблемой как пользователь 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 функция.
Реализовал в своем проекте пункты 2, 3, 4 несколько лет назад (кажется году эдак в 2013). На основе этого функционала сделал систему плагинов в приложении, а потом еще добавил систему обновлений (self-update).
И сводилось все действительно к одно команде:
Планировал написать об этом статью на хабре, но руки так и не дошли.
Ошибся со ссылкой для happy-types/enumerable-type.
огорчу. кеш есть.
Для сравнения добавил в тест:
Результат:
билд и сорцы.
Попробовал реализацию через рефлексию. Оказалось действительно в чем-то удобнее. Спасибо что просветили.
Проблему с человеческим описанием в myclabs/php-enum можно решить так:
Но вот решил я сравнить производительность реализации через рефлексию и с явным описанием вариантов значений и получилось что рефлексия в 3-4 раза медленнее в зависимости от версии php.
Тест no magic это тест без использования магических функций
__call()и__callStatic()и даже он оказывается медленнее в 3 раза.Отсюда делаем вывод. За удобство нужно платить.
Я бы посоветовал, прежде чем делать большой PR, сначала обсудить его в issues с мейнтейнером. Это поможет избавиться от лишней работы и предвидеть правки PR. Хотя по моему опыту на PR мейнтейнеры реагируют активнее.
Врет. Я только выкладывал сорцы по просьбе трудящихся. Автор не я.
Ох, если бы тот же самый.
Не скажу что xdebug плох. Просто мне лично он на подходит. Хотя бы потому что медленный.
PS: Я не пиарюсь. Это не моя либа.
Уже несколько лет пользуюсь вот этой либой для отладки кода. Удобный аналог var_dump. Гараздо более читаемый и юзабельный. Рендер под web и в cli. Удобное отображение ошибок. Удобней чем в xdebug.
@springimport я в результате так и делаю. Как я и сказал, пишу свой велосипеде и выкладываю его на GitHub. Но это не совсем правильно, о чем я уже написал.
Что хорошего в том что каждый будет писать свою реализацию функциональности и постить ее на GitHub?
Просто для примера, список реализаций CQRS на PHP.
Я просмотрел около 20 проектов из списка, не найдя удобно мне сделал свою реализацию и думаю выложить её на GitHub. Хорошо ли это? Не уверен.
Я неоднократно сталкивался с похожей проблемой как пользователь 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 функция.