Clause de non-responsabilité :Je suis le responsable du projet Spring Data. Je vais donc principalement couvrir le côté Spring Data ici :
Je pense que la principale distinction entre les deux projets est que l'équipe Hibernate OGM a choisi de centrer ses efforts sur le JPA, contrairement à l'équipe Spring Data. Les raisons sont les suivantes :
- JPA est une API intrinsèquement relationnelle. Les deux premières phrases de la spécification indiquent qu'il s'agit d'une API pour le mappage objet-relationnel. Ceci est également incarné dans les thèmes centraux de l'API :il parle de tables, de colonnes, de jointures, de transactions. Des concepts qui ne sont pas nécessairement transférables dans le monde NoSQL.
- Vous choisissez généralement un magasin NoSQL en raison de ses caractéristiques particulières (par exemple, des requêtes géospatiales sur MongoDB, la possibilité d'exécuter des traversées de graphes pour Neo4j). Aucune d'entre elles n'est (et ne sera) disponible dans JPA, vous devrez donc de toute façon fournir des extensions propriétaires.
- Pire encore, JPA propose des concepts qui guideront simplement les utilisateurs dans de mauvaises directions s'ils supposent qu'ils travaillent sur un magasin NoSQL tel qu'ils ont été définis dans JPA :comment une annulation de transaction devrait-elle être raisonnablement mise en œuvre sur une base de données MongoDB ?
Ainsi, avec Spring Data, nous avons choisi de fournir plutôt un modèle de programmation cohérent pour les magasins pris en charge, mais n'essayez pas de tout forcer dans une seule API trop abstraite :vous obtenez les implémentations de modèles bien connues, vous obtenez l'abstraction du référentiel, qui fonctionne de la même manière pour tous les magasins, mais vous permet de tirer parti des fonctionnalités et des concepts spécifiques au magasin.