Об ORM
Немного напишу про ОРМ. Не стану рассуждать, хорошо это или плохо, хочу обратить внимание на следующие типичные заблуждения и ограничения. Если от них отказаться, то решения становятся проще и дешевле
1. ORM это фреймворк - всё должно строиться вокруг него.
Нет, не надо так делать. Если у вас не data-driven приложение, в котором таблицы и данные присутствуют в терминологии самих пользователей, то слой персистенстности лучше запрятать подальше, как от пользователя, так и от разработчика. Идеальная картина мира -- когда с объектами БД можно работать как с коллекцией в идеальной памяти, которая транзакционная, бесконечной ёмкости и т.п. Чем ближе к этой модели слой доступа к данным, тем обычно лучше. Rails со своим Active Record, что ни говори, достаточны для многих применений, а проблемы начинаются там, где от этой модели persistence ignorance отклонились (и полезли детали, всякие .save в ActiveRecord).
2. ORM в приложении должен быть один.
Вовсе нет. Правильнее относиться к нему как к обычной библиотеке. Нередко два разных легковесных маппера в разных частях приложения могут быть лучшим решением, чем один большой тяжёлый комбайн. ORM это не священная корова.
3. Самописный будет простой и гибкий, а взятый снаружи -- медленный и трудно настраиваемый.
Тоже нет. Так будет до некоторого момента, когда вы обнаружите, что было реализовано ровно то, что есть на рынке, только с дефектами, с меньшим количеством фич и непонятной стоимостью поддержки.
На практике очень часто это заблуждение сочетается с 1, и тогда приходится дообучать разработчика пользоваться мегабиблиотекой, которая вне компании не представляет ценности.
4. Взял ORM - забудь про SQL
Тоже нет. Наиболее оптимальные и производительные решения -- те, которые сочетают нативные запросы в критичных местах с удобством применения ORM в типовых местах. Делайте так же.
ORM это ОЧЕНЬ СЛОЖНО. В существующем продукте (Hibernate, MyBatis, тысячи их) уже решено неимоверное количество очевидных и не очень очевидных нюансов. Не пишите своё, переиспользуйте готовое.