Ладно, обсуждение идёт не в том ключе. Все делают в

целом одинаково, вопрос был в другом, а нужно ли оно вообще в некоторых случаях?! На эту тему, к сожалению нет видео с доклада и сам я его не видел, но бегло смотрел тезисы, но там нет толком ничего. https://phprussia.ru/moscow/2021/abstracts/7654

Почему не в том ключе? Лекцию гляну, спасибо)

там, к соджалению, мало полезного, только слайды. Я жду когда видео появится и интересно посмотреть на этот опыт. Про "не в том ключе" я про то, что довод свелся к тому, что надо только так, не очень хочется переубеждать и доказывать, это не возможно, когда человек к этому не готов :)

Ну в общем, это к тому же junior/middle/senior и «enterprise» разработке. Чем выше твои скилы и кол-во технологий которыми ты владеешь, тем меньше ты хочешь использовать/вспоминать то с чего ты начинал, думая об этом как о «что, зачем, я ведь это 5-10 лет назад учил!». На практике нормальный разраб познается в понимании того когда можно срезать углы и когда уместнее использовать нативное решение вместо пакета/паттерна/etc. А вообще за всеми вопросами о карьерном росте обращайтесь к @faqphp 😉

Так и есть. Много зависит от разных факторов, сейчас у всех фактор фреймворк и инструменты которые он даёт и ограничения в рамках компании в которой они работают и одобрят ли их решения тех лид или код ревьюер. Я к счастью уже сам могу себе такие вопросы задавать и принимать решения. Да и опыт других команд показывает, что QueryBuilder не даёт гарантии что его использование позволит перейти на другую БД в виду специфичных возможностей, да и бд менять а работающем проекте так себе идея.

А что я? Я джун.

Имеешь ввиду Junior-Senior+++? 😉

Ну если мы говорим к примеру, о MySql и PostgreSql в высоконагруженном проекте, тогда конечно - берите паттерн «репозиторий», пишите в нем нативный sql учитывающий нюансы в различии синтаксиса между этими СУБД и будет вам свой, собственный - “query-builder”*

Ну собственно разговор был не об этом. В своих проектах я знаю что использовать и почему. Мы опять ушли в сторону

А в ларке, как по мне, это не имеет сысла, здесь мало кто по этму пути пойдет, проще сменить фреймворк, чем сюда затащить нормально репозиторий и все остальное

ты прям лучший пиарщик книги последнее время)

Стараюсь😉 Очень зашла🙏

да я проходил этот путь уже с Doctrine, CycleORM и т.д. Я не говорю что нельзя и это не получится, а про то, что без доктрины будет каша и желание испольщзовать связи моделей, а с доктриной нафига тогда Ларка?

😂😂😂

Вы пришли к мысли Димы Кожанова)

а мы про другое говорили

Выкидывай query-builder, eloquent, да и лару тоже. Шучу!

ларка и без элоквента неплоха. чотыужпрям

Ну я не спорю :) Когда внедряли CycleORM, то в целом все работало и было норм. Но потом возникал вопрос, а что такого дает ларка?!

смотря с чем сравнивать...

Помимо бд(?) - экосистему и сообщество

Кстати, есть ли какой-то «фонд» оплаты труда за написание книги, что бы кинуть донат по желанию (аля Github Sponsors)?

да мне как-то стыдно за такое собирать. Оно плагин пиарит неплохо

)))))

Хорошо что с плагином все хорошо) Ты кстати случаем не знаешь, Github файлики из /manuscript нормально индексируются поисковиками? Xочется что бы книга была доступна/известна большему кол-ву людей.

а я её скоро буду дорабатывать и на английский

Супер!

Обновлять под 8-9* версию планируешь?

допишу парочку

Спасибо

Надотоже будет что нить дописать. Я люблю таким заниматься. Кстати я недавно купил курс о spatie по eventsourcing

и как?