Вы не понимаете, что вы сделали. Я не говорю про подорожание памяти. Да, память подорожала в том числе и потому что вы генерите котиков и код. Но это мелочи. Небольшие побочные эффекты.

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

Да, мир не станет никогда прежним. Как он уже не станет "доинтернетным". Но вы не умеете новым миром пользоваться. Вы его вкалываете внутривенно, увеличивая дозу и не думая о последствиях. Это убьёт всех. Вас, меня, их.

Я расскажу почему. Скорее всего вам не захочется это знать. Это будет здесь, за этой кнопкой. Решать вам.

Разработка софта всегда была поиском баланса между разными аспектами, вроде скорости разработки (как быстро ты выкатываешь новые фичи), производительности приложения, потребления им памяти, красотой интерфейса и отполированностью логики.

В большинстве случаев скорость разработки важнее, чем производительность и потребление памяти.

ORM — это как раз инструмент, экономящий время разработки. Но за счёт чего?

У реляционных баз данных есть один небольшой недостаток - они не выводят табличные данные на экран пользователя. С одной стороны - какой же это недостаток, когда технология занимается исключительно своими базаданновыми вещами и не лезет туда, где её не надо. С другой - приходится данные пробрасывать через другой язык программирования, а то и два-три в случае веба. Ну и сам язык запросов забывать не надо. Он тоже вроде как язык.

Все существующие языки предназначены для уменьшения цифровой энтропии и оснащены инструментами для уборки цифрового навоза (кроме брейнфака, пожалуй). В том числе и инструментами для сбора в кучу разрозненных полей, да ещё и с возможностью как-то назвать эту структуру. В ООП языках это вообще часть парадигмы с далеко идущими последствиями, можно сказать, это у них в крови. А ООП языков, работающих между БД и экраном пользователя, осмелюсь предположить, большинство. Естественно, у разработчика возникает сразу желание воспользоваться структурными инструментами языка, чтобы утрамбовать поля таблицы в класс. Вот так и появляются дтошечки, энтитички, поджошечки и прочие попочки.

И вроде не велика проблема - делаем структуру в нашем любимом языке, такую же, как в БД и из наших кубиков складывается слово "счастье". Складываться-то оно складывается, но ненадолго. Очень быстро структура БД и структура в коде начинают разъезжаться. А если не начинают, то потыкайте в свой проект палочкой - скорее всего он уже умер. Как говорится "не щебечет дохлый щегол, а мёртвый проект не меняет свою структуру". Ну и далее по тексту...

Нет, речь не про кэш в памяти. Так было бы слишком просто. У нас сегодня будет препарирован ORM, который честно запрашивает данные у реляционной СУБД, маппит в объекты, подключает связи и отдаёт в логику приложения в виде объектов. И всё на порядки быстрее, чем прямой запрос из кода приложения.

Да, здесь есть нюанс. Об этом нюансе, а также о том, зачем я написал в пятый раз кастомный ORM и будет эта статья. Эта разработка тесно переплетена с моей личной историей, когда я переходил с одной работы на другую, а затем был уволен. Я не хочу оставлять сухой технический текст, поэтому эта статья будет скорее рассказом моей работе в этой компании.

Код в статью я старался включать по минимуму. Он точно не полный и возможно ошибочный, потому что дорабатывался по мере написания статьи. Полный и исправленный вариант будет доступен по ссылке в конце статьи.

Если вы не читали мою предыдущую статью, то и не читайте. Статья получилась короткая, скомканная, и, самое главное, не отвечала на вопрос, как именно ORM может помочь в повседневной работе программиста.

Сегодня попробую восполнить этот пробел и рассказать, как упрощается написание логики на примере одной экстремальной ORM. В которой базы данных не существует.

Если позволите, начну с небольшого исторического экскурса на 30 секунд, о том, как эта система появилась.

На самом деле это нужно было сделать давно. Вот ровно тогда, когда вы поняли, что будете работать с базой данных. Сейчас, конечно, внедрить уже сложнее, чем на старте, но ещё не поздно.

Сегодня я буду навязывать своё субъективное, однобокое, единственно правильное мнение, зачем вам ORM.