Haftungsausschluss:Ich bin der Leiter des Spring Data-Projekts, daher werde ich hier hauptsächlich die Spring Data-Seite behandeln:
Ich denke, der Hauptunterschied zwischen den beiden Projekten besteht darin, dass das OGM-Team von Hibernate sich entschieden hat, seine Bemühungen auf die JPA zu konzentrieren, während das Team von Spring Data dies ausdrücklich nicht tat. Die Gründe sind wie folgt:
- JPA ist eine von Natur aus relationale API. Die ersten beiden Sätze der Spezifikation besagen, dass es sich um eine API für objektrelationales Mapping handelt. Dies wird auch in den Kernthemen der API verkörpert:Sie spricht über Tabellen, Spalten, Joins, Transaktionen. Konzepte, die nicht unbedingt in die NoSQL-Welt übertragbar sind.
- In der Regel wählen Sie einen NoSQL-Speicher aufgrund seiner besonderen Merkmale (z. B. Geodatenabfragen auf MongoDB, die Möglichkeit, Graph-Traversals für Neo4j auszuführen). Keine davon ist (und wird) in JPA verfügbar, daher müssen Sie sowieso proprietäre Erweiterungen bereitstellen.
- Noch schlimmer ist, dass JPA Konzepte enthält, die Benutzer einfach in falsche Richtungen führen, wenn sie davon ausgehen, dass sie an einem NoSQL-Speicher arbeiten, wie er in JPA definiert wurde:Wie sollte ein Transaktions-Rollback vernünftigerweise auf einer MongoDB implementiert werden?
Daher haben wir uns bei Spring Data dafür entschieden, ein konsistentes Programmiermodell bereitzustellen für die unterstützten Stores, aber versuchen Sie nicht, alles in eine einzige übermäßig abstrahierende API zu zwingen:Sie erhalten die bekannten Vorlagenimplementierungen, Sie erhalten die Repository-Abstraktion, die für alle Stores identisch funktioniert, aber Sie können Store-spezifische Funktionen und Konzepte nutzen.
