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

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

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

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

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

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

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

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