[Architekturdesign] Wie führe ich SQL in einer Java-Anwendung aus? 2WaySql vs ORM

Wenn Sie SQL in einer Java-App ausführen, fragen Sie sich, was Sie verwenden sollen. Ich habe einen Artikel für eine solche Person geschrieben.

Abschließend wird 2WaySql (DBFlute, UroboroSQL, Doma usw.) persönlich empfohlen.

Annahme: Bei der Entwicklung einer mittelgroßen oder größeren Geschäftsanwendung mit Dutzenden von Entwicklern

Die Funktionen von 2WaySql sind wie folgt.

SQL wird in einer externen Datei beschrieben
Funktioniert sowohl mit Apps als auch mit SQL-Clients

Was gut ist, ist ...

Sei flexibel. Es ist einfach zu entwickeln, da es in eine externe Datei umgewandelt wird und SQL wie mit einem SQL-Client ausgeführt werden kann. Es ist auch einfach, zu anderen Sprachen als Java zu wechseln, und es ist einfach, zu anderen Plattformen zu wechseln.
Wenn eine Abfrage (Kriterien-API, JPQL, SQL usw.) direkt in Java geschrieben wird, hängt dies von Java ab und die Migration ist gering.
Entwicklungsseite Es ist einfach zu entwickeln, da nur SQL geschrieben wird. Es ist in Ordnung, auch wenn die Entwicklerstufe niedrig ist.
Sie müssen sich nicht an Criteria API, JPQL oder andere produktspezifische Produkte erinnern
Hervorragend in Bezug auf die Leistung. Es ist einfach, SQL zu optimieren, da es einfach ist, Hinweise hinzuzufügen und die SQL-Struktur zu ändern (z. B. die Verknüpfungsreihenfolge zu ändern).
Die Leistungsoptimierung ist beim Schreiben in ORM ohne SQL schwierig.
Bedienbarkeit Da es in eine externe Datei umgewandelt wird, ist es einfach, den Einflussbereich und die statische Überprüfung zu untersuchen (z. B. das Verbot mit Klausel).
Wenn eine Abfrage (Kriterien-API, JPQL, SQL usw.) direkt in Java geschrieben wird, ist es sehr schwierig, den Einflussbereich zu untersuchen, da er von Java abhängt. Es ist eine Verschwendung zu untersuchen, wie viele SQLs es gibt. Es mag eine Meinung geben, dass es auf der DB-Seite beurteilt werden kann, aber es ist schwierig zu untersuchen, da es SQL für die Integritätsprüfung und SQL gibt, die von anderen als der Anwendung aufgerufen werden.
Wenn es sich bei ORM nicht um Leistung handelt oder wenn es sich um eine komplizierte Abfrage handelt, werden Sie am Ende SQL schreiben, aber ich habe verschiedene Abfragen geschrieben, z. B. SQL-less, mit SQL (externe Datei), mit SQL (Java Direct Writing). Es ist in der Regel außer Kontrolle geraten und es ist schwierig, das Ausmaß der Auswirkungen zu untersuchen.

Wenn ich mir das oben anschaue, mag es scheinen, dass ich ORM hasse, aber ... Als "individueller" Entwickler benutze ich es gerne! !! ORM ist ehrlich gesagt sehr praktisch! !! Es ist jedoch zu bequem und ich kann verschiedene Dinge tun. Wenn es viele Entwickler gibt, ist es schwierig zu kontrollieren. Die Verwendung von ORM ist also ein System, das viel einfaches SQL ausgibt (z. B. Referenz-API). Ich denke, es sollte begrenzt sein, wenn es gebaut wird. Wenn der ORM entsprechend verpackt wird, gibt es Einschränkungen für die Funktionen, die von Entwicklern systemweise verwendet werden können. Ich denke ich muss.