[Conception d'architecture] Comment exécuter SQL dans une application Java? 2WaySql contre ORM

Lorsque vous exécutez SQL dans une application Java, vous vous demandez quoi utiliser. J'ai écrit un article pour une telle personne.

En conclusion, 2WaySql (DBFlute, uroboroSQL, Doma, etc.) est personnellement recommandé.

Hypothèse: lors du développement d'une application commerciale de taille moyenne ou plus grande avec des dizaines de développeurs

Les fonctionnalités de 2WaySql sont les suivantes.

SQL est décrit dans un fichier externe
Fonctionne à la fois à partir d'applications et de clients SQL

Ce qui est bien c'est ...

Être flexible. Il est facile à développer car il est transformé en fichier externe et SQL peut être exécuté tel quel avec un client SQL. De plus, il est facile de passer à des langages autres que Java, et il est facile de passer à d'autres plates-formes.
Si une requête (Criteria API, JPQL, SQL, etc.) est écrite directement en Java, cela dépend de Java et la migration est faible.
Côté développement C'est facile à développer car il s'agit simplement d'écrire du SQL. C'est OK même si le niveau de développeur est bas.
Pas besoin de se souvenir de l'API Criteria, de JPQL ou d'autres produits spécifiques au produit
Excellent en termes de performances. Il est facile d'ajuster SQL car il est facile d'ajouter des conseils et de modifier la structure SQL (comme la modification de l'ordre de jointure).
Le réglage des performances est difficile lors de l'écriture dans ORM sans SQL.
Opérabilité Puisqu'il est transformé en fichier externe, il est facile d'étudier la plage d'influence et le contrôle statique (comme l'interdiction avec clause).
Si une requête (API Criteria, JPQL, SQL, etc.) est écrite directement en Java, il sera très difficile d'étudier la plage d'influence car elle dépend de Java. C'est un gaspillage d'enquêter sur le nombre de SQL. Il peut y avoir une opinion selon laquelle il peut être jugé du côté de la base de données, mais il est difficile d'enquêter car il existe du SQL pour la vérification de l'état et du SQL appelé depuis une autre application que l'application.
En ORM, si ce n'est pas de la performance ou s'il s'agit d'une requête compliquée, vous finirez par écrire du SQL, mais j'ai écrit diverses requêtes telles que SQL-less, avec SQL (fichier externe), avec SQL (écriture directe Java), Il a tendance à être hors de contrôle et difficile d'enquêter sur l'étendue de l'impact.

En regardant ce qui précède, il peut sembler que je déteste ORM, mais ... En tant que développeur "individuel", j'aime l'utiliser! !! ORM est honnêtement très pratique! !! Cependant, c'est trop pratique et je peux faire diverses choses. Quand il y a beaucoup de développeurs, c'est difficile à contrôler. Donc, personnellement, utiliser ORM est un système qui émet beaucoup de SQL simple (comme l'API de référence). Je pense qu'il devrait être limité lors de sa construction. Ou, en encapsulant l'ORM de manière appropriée, il existe des restrictions sur les fonctions qui peuvent être utilisées par les développeurs système par système. Je pense que j'en ai besoin.