От Doctrine ORM к CQRS за 20 минут (Дмитрий Симушев, Райффайзенбанк)

[@SkyengITeam]

Запись доклада Дмитрия с PHP-митапа, прошедшего в ноябре 2019го в Москве. 01:00 Что такое ORM и точно ли она нужна вам 03:46 Две группы задач с Doctrine: запись и чтение. Почему с одной из них возникают проблемы? 11:13 Команды и запросы в CQRS 15:17 Комбинируем ORM и SQL+ PDO и берем от них только лучшее 17:09 Вопросы докладчику

[@ЯковЛазоренко]

Хороший доклад, теперь я понял, что такое CQRS и для чего он нужен.

[@backendtv1345]

Огонь, спасибо!

[@Vadim.Bondarenko]

Интересно почему в докладе не было не слова про nativQueury, которые доктрина прекрасно поддерживает и отключения гидрации на уровне запроса

[@ArlekinLaMort]

а зачем она тогда нужна?

[@Carrion-Crow]

Потому что Докладчик васелиса, не хочет думать и решать проблемы красиво, сделал гауно и теперь все будут страдать, судя по работе их приложения уже видно что там пи...ц

[@tasatko]

CQRS не решает вопрос с желанием выкинуть ORM а усугубляет его.

[@kion9138]

А что делать при рефакторинге? Например мы переименовали атрибут в сущности. Если мы переименуем ее средствами рефакторинга PHP STORM, то он нам автоматом поменят везде где оно используется. А как быть с запросами и ДТОшками, мы про них можем забыть.

[@kinvain]

Аттрибут модели записи и DTO !== поле в таблице. Тут только вопрос где именно менять. Переименовывание аттрибута, в теории, вообще не должно никак не сказываться на запись и чтение. Переменовать поле в таблице, несколько опаснее так как могут отвалиться и команды/запись и запросы/чтение. Про запись. Если мы переименовываем аттрибут, то IDE его везде заменит, но на уровне модели записи связь сохраниться. Что данный аттрибут предоставляет данные для данного поля. Например, у нас есть таблица с полем deleted где мы храним timestamp когда запись была удалена. Первоначально модель записи имела аттрибут с точно таким же названием $deteled и описывая модель записи мы однозначано указали что $deleted это аттрибут для поля deleted. Потом решили переменовать аттрибут в $deletedOn. IDE просто меняет везде название аттрибута, но то что он указывает на поле deleted - сохраняется. То есть запись не ломается. Чтение работает точно так же. При этом модель чтения вообще ничего не знает про запись. У модели чтения есть только связь между своим аттрибутом, которое, допустим, называется $deletedAt и полем в таблице deleted. Соответсвенно, связь сохраняется и чтетение работает. Плюс, тут точно такой же принцип как выше. Мы можем переменовать аттрибут модели чтения, но он по прежнему будет получать данные из того же самого поля. Переименовать поле в таблице - сложнее. Особенно если приложения записи и чтения разделены. Но давайте честно - как часто нужно переменовывать поля? Мой опыт говорит что вероятность крайне мала. Но даже если такое произойдёт то большой беды нет. Просто работа пойдёт с другой стороны. Если в одни день мы решили поле deleted в таблице переменовать в deleted_at то поправить модели записи и чтения может быть даже ещё проще. Мы просто указываем у моделей что их аттрибут $deletedOn теперь указывает на поле deleted_at. С записью должно решаться на раз. Это просто найти модели, которые пишут в изменённую таблицу и поправить указатель на поле. С чтением чуть сложнее - нужно найти именно SQL запросы и поменять в них поле.

[@Carrion-Crow]

Ну епт теперь понятно почему у них все так долго работает, изобрели хер пойми что хер пойми зачем, кому что упростили не понятно, оверхеды на гидрацию можно устранить переведя гидрацию в скаляр, тогда выхлоп будет долше конечно чем при PDO но там разница будет в сотых долях секунды. Вобщем я бы уволил этого человека.... как после его велосипеда теперь там люди будут работать и разбиратся с этим гавном, не понятно. для остальных скажу, если у вас будет стоять 2 стула на первом будет удобство но медление на секунды а на втором неудобно зато быстрее на секунды. ТО ДАЖЕ НЕ ДУЙМАЙТЕ, садитесь на первый, вам за это потом еще спасибо скажут

[@Carrion-Crow]

@@MyName-tg8ek Да ни чего не будет, если страница грузится секунду то она и грузится секунду всега, если стала грузиться дольше и ни кто ни че не далал в коде то значит у вас большая на грузка на сервер(много клиентов) и это уже дело админой. Можно конечно садиться и оптимизировать и даже нужно, я тут говорю о том что оптимизация которая приводит архитектуру проекта в кашу это не оптимизация

[@denis_hromov]

Да уж.. выхлоп с этого смешной на 99% уверен. Если так уж важны миллисекунды, почему бы не перенести высоконагруженный сервис\эндпоинт на go?