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

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

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

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

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

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

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

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

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

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

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

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

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

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