Я думаю, что вы уже определили основной компромисс, связанный с программным обеспечением ORM.Каждый раз, когда вы добавляете новый уровень абстракции, который пытается обеспечить обобщенную реализацию того, что вы делали вручную, произойдет некоторая потеря производительности / эффективности.
Как вы заметили, обход нескольких отношений, таких как a.b.c.d
, может быть неэффективным, потому что большинство программ ORM будет выполнять независимый запрос к базе данных для каждого .
по пути.Но я не уверен, что это означает, что вы должны полностью исключить ORM.Большинство решений ORM (или, по крайней мере, конечно, Hibernate) позволяют вам задавать пользовательские запросы, где вы можете вернуть именно то, что вы хотите в одной операции базы данных.Это должно быть примерно так же быстро, как ваш выделенный SQL.
На самом деле проблема в том, чтобы понять, как слой ORM работает за кулисами, и понять, что хотя что-то наподобие a.b.c.d
просто написать, то, что заставляет слой ORM делать, когда он оценивается, не,Как правило, я всегда начинаю с самого простого подхода, а затем пишу оптимизированные запросы в тех областях, где это имеет смысл / где очевидно, что простой подход не масштабируется.