Ich nehme an, dass Sie tatsächlich ein Objektmodell haben, das reicher ist als bloße DTOs und nicht einfach eine 1: 1-Korrespondenz mit Ihrem relationalen Schema. Wenn nicht, gewinnst du das Argument nicht.
Sie gewinnen, wenn das von Hibernate generierte SQL mindestens so effizient ist wie das handcodierte Zeug, das in den gespeicherten Procs gespeichert ist.
Sie verlieren, wenn die gespeicherten Prozeduren optimiert werden können, um besser zu funktionieren als von Hiberate generiertes SQL.
Sie verlieren, wenn die Datenbank von anderen Apps geteilt wird, die von den gespeicherten Procs abhängen. Sie können die Logik nicht so einfach auf Spring und die mittlere Ebene verschieben.
Sie haben einen besseren Fall, wenn Ihre App die Datenbank besitzt.
Da Sie bereits Spring verwenden, deutet dies darauf hin, dass Sie eine DAO-Ebene haben, die die Spring-Validierung nutzt. PreparedStatements werden bereits darunter verwendet, sodass die SQL-Injektion für Spring genauso unwahrscheinlich ist wie für gespeicherte Procs.
Okay, ich werde hier den Anwalt des Teufels spielen.
Gespeicherte Prozeduren sind eine Ebene der Abstraktion. JPA erfordert, dass Sie die zugrunde liegende Tabellenstruktur kennen. Gespeicherte Prozeduren / Funktionen maskieren das; Sie müssen nur wissen, welche Prozedur oder welche Funktion aufgerufen wird und welcher Rückgabetyp ist.
JDBC macht das Aufrufen gespeicherter Prozeduren sehr einfach, indem das prepareCall Methoden.
Gespeicherte Prozeduren fügen außerdem eine Sicherheitsschicht hinzu: Die Anwendung selbst kann die Tabellen normalerweise nicht manuell ändern, sondern nur die Prozeduren aufrufen, die die Änderung vornehmen. Der SP / SF sollte auch die übergebenen Argumente validieren.
Der größte Nachteil gespeicherter Prozeduren besteht darin, Daten zurück zu bekommen ... Sie müssen Ihre eigene Einrichtung erstellen, um Arrays und Strukturen zuzuordnen, die zu Java-Objekten zurückkommen, normalerweise mit einem p>
Also wie und was zu sagen / präsentieren / erklären / Argument, um zumindest ihre Haltung gegenüber ORM zu verschieben?
Fragen Sie, ob Sie für jeden neuen Entitätstyp, den Sie Ihrer Anwendung hinzufügen, weiterhin denselben SQL-JDBC-CRUD-Code schreiben möchten.
Ohne eine ORM-Lösung in der Datenschicht benötigt jede neue Entitätsklasse N Arbeitseinheiten, um diese Entität über die Datenschicht verfügbar zu machen (DAOs, CRUD-Code, gespeicherte Prozeduren, Schreibabfragen usw.).
ORM transformiert dieses N in einen Bruchteil von sich selbst, vorausgesetzt, dass das Hinzufügen neuer Entitäten dann erfordert, dass Sie einfach eine andere Zuordnung für diese Entität in Metadaten hinzufügen.
Ich denke diese Antwort aus dem Link für verwandte Fragen führt zu dem zugrunde liegenden Problem. Wenn der Zweck der Datenbank eng mit Ihrer Anwendung verknüpft ist und sie nicht wirklich eine eigene Identität hat, ist ORM sehr sinnvoll.
Wenn Ihre Datenbank jedoch ein größeres Bild darstellt und Ihre Anwendung eine der vielen Anwendungen ist, die auf Daten zugreifen, kann die Verwendung von ORM potentiell negative Auswirkungen auf die Kopplung zwischen Ihrer Anwendung und der Datenbank und die Notwendigkeit, die Datenbank zu ändern, haben Zeit.
Aber bis zu einem gewissen Grad können Sie Ihre Frage selbst beantworten - welche Einwände hatten Sie? Wie wurdest du das erste Mal überzeugt?
Die Antwort auf Ihre Frage ist eigentlich ziemlich einfach und völlig unabhängig davon, ob Sie ein eingefleischter DBA sind. Sie müssen sich fragen:
Schreiben Sie eine domänenmodellzentrische Anwendung mit vielen CRUD?
Oder schreiben Sie eine relationale Modell-orientierte Anwendung mit nicht so viel CRUD?
Wählen Sie im ersten Fall ein ORM. Im zweiten Fall wählen Sie SQL. Wenn Sie beide in Ihrer Anwendung haben, wählen Sie beide. Die beiden Modelle schließen sich nicht gegenseitig aus, obwohl ORMs eine Menge Regeln für das Anwendungsdesign festlegen.
Beachten Sie, dass ORMs nicht "das nächste Ding" in der Java-Welt sind. Sie sind eine großartige Erfindung, um nur einige Probleme (nämlich komplexe oder repetitive CRUD) zu lösen