Voici une introduction à chaque technologie mentionnée.
Printemps-DAO
Spring-DAO n'est pas un module spring au sens strict, mais plutôt des conventions qui devraient vous imposer d'écrire DAO, et de bien les écrire. En tant que tel, il ne fournit ni interfaces, ni implémentations, ni modèles pour accéder à vos données. Lorsque vous écrivez un DAO, vous devez les annoter @Repository
afin que les exceptions liées à la technologie sous-jacente (JDBC, Hibernate, JPA, etc.) soient systématiquement traduites dans la DataAccessException
sous-classe appropriée .
Par exemple, supposons que vous utilisiez maintenant Hibernate et que votre couche de service attrape HibernateException
afin d'y réagir. Si vous passez à JPA, vos interfaces DAO ne devraient pas changer, et la couche de service sera toujours compilée avec des blocs qui capturent HibernateException
, mais vous n'entrerez jamais ces blocs car vos DAO lancent maintenant JPA PersistenceException
. En utilisant @Repository
sur votre DAO, les exceptions liées à la technologie sous-jacente sont traduites en Spring DataAccessException
; votre couche de service intercepte ces exceptions et si vous décidez de changer la technologie de persistance, le même Spring DataAccessExceptions
sera toujours lancé car Spring a traduit les exceptions natives.
Notez cependant que cette utilisation est limitée pour les raisons suivantes:
- Vous ne devez généralement pas intercepter les exceptions de persistance, car le fournisseur peut avoir annulé la transaction (en fonction du sous-type d'exception exact), et vous ne devez donc pas continuer l'exécution avec un autre chemin.
- La hiérarchie des exceptions est généralement plus riche dans votre fournisseur que ce que Spring fournit, et il n'y a pas de mappage définitif d'un fournisseur à l'autre. S'en remettre à cela est dangereux. C'est cependant une bonne idée d'annoter vos DAO
@Repository
, car les beans seront automatiquement ajoutés par la procédure d'analyse. De plus, Spring peut ajouter d'autres fonctionnalités utiles à l'annotation.
Spring-JDBC
Spring-JDBC fournit la classe JdbcTemplate, qui supprime le code de plomberie et vous aide à vous concentrer sur la requête et les paramètres SQL. Il vous suffit de le configurer avec un DataSource
, et vous pouvez ensuite écrire du code comme celui-ci:
int nbRows = jdbcTemplate.queryForObject("select count(1) from person", Integer.class);
Person p = jdbcTemplate.queryForObject("select first, last from person where id=?",
rs -> new Person(rs.getString(1), rs.getString(2)),
134561351656L);
Spring-JDBC fournit également un JdbcDaoSupport, que vous pouvez étendre pour développer votre DAO. Il définit essentiellement 2 propriétés: un DataSource et un JdbcTemplate qui peuvent tous deux être utilisés pour implémenter les méthodes DAO. Il fournit également un traducteur d'exceptions des exceptions SQL vers Spring DataAccessExceptions.
Si vous prévoyez d'utiliser jdbc plain, c'est le module que vous devrez utiliser.
Printemps-ORM
Spring-ORM est un module parapluie qui couvre de nombreuses technologies de persistance, à savoir JPA, JDO, Hibernate et iBatis. Pour chacune de ces technologies, Spring fournit des classes d'intégration afin que chaque technologie puisse être utilisée selon les principes de configuration de Spring et s'intègre en douceur avec la gestion des transactions Spring.
Pour chaque technologie, la configuration consiste essentiellement à injecter un DataSource
bean dans une sorte de bean SessionFactory
ou EntityManagerFactory
etc. Pour le JDBC pur, il n'y a pas besoin de telles classes d'intégration (à l'exception de JdbcTemplate), car JDBC ne repose que sur un DataSource.
Si vous prévoyez d'utiliser un ORM comme JPA ou Hibernate, vous n'aurez pas besoin de spring-jdbc, mais uniquement de ce module.
Spring-Data
Spring-Data est un projet parapluie qui fournit une API commune pour définir comment accéder aux données (annotations DAO +) d'une manière plus générique, couvrant à la fois les sources de données SQL et NOSQL.
L'idée initiale est de fournir une technologie pour que le développeur écrit l'interface pour un DAO (méthodes de recherche) et les classes d'entités de manière indépendante de la technologie et, en se basant uniquement sur la configuration (annotations sur les DAO & entités + configuration du ressort, que ce soit xml ou java), décide de la technologie d'implémentation, que ce soit JPA (SQL) ou redis, hadoop, etc. (NOSQL).
Si vous suivez les conventions de dénomination définies par spring pour les noms des méthodes de recherche, vous n'avez même pas besoin de fournir les chaînes de requête correspondant aux méthodes de recherche pour les cas les plus simples. Pour d'autres situations, vous devez fournir la chaîne de requête à l'intérieur des annotations sur les méthodes de recherche.
Lorsque le contexte d'application est chargé, spring fournit des proxys pour les interfaces DAO, qui contiennent tout le code standard lié à la technologie d'accès aux données, et appelle les requêtes configurées.
Spring-Data se concentre sur les technologies non SQL, mais fournit toujours un module pour JPA (la seule technologie SQL).
Et après
Sachant tout cela, vous devez maintenant décider quoi choisir. La bonne nouvelle ici est que vous n'avez pas besoin de faire un choix final définitif pour la technologie. C'est en fait là que réside la puissance de Spring: en tant que développeur, vous vous concentrez sur l'entreprise lorsque vous écrivez du code, et si vous le faites bien, changer la technologie sous-jacente est un détail d'implémentation ou de configuration.
- Définissez un modèle de données avec des classes POJO pour les entités et des méthodes get / set pour représenter les attributs d'entité et les relations avec d'autres entités. Vous aurez certainement besoin d'annoter les classes d'entités et les champs en fonction de la technologie, mais pour l'instant, les POJO suffisent pour commencer. Concentrez-vous simplement sur les besoins commerciaux pour le moment.
- Définissez des interfaces pour vos DAO. 1 DAO couvre exactement 1 entité, mais vous n'aurez certainement pas besoin d'un DAO pour chacune d'elles, car vous devriez pouvoir charger des entités supplémentaires en naviguant dans les relations. Définissez les méthodes de recherche en suivant des conventions de dénomination strictes.
- Sur cette base, quelqu'un d'autre peut commencer à travailler sur la couche de services, avec des simulations pour vos DAO.
- Vous apprenez les différentes technologies de persistance (sql, no-sql) pour trouver la meilleure solution pour vos besoins et choisissez l'une d'entre elles. Sur cette base, vous annotez les entités et implémentez les DAO (ou laissez spring les implémenter pour vous si vous choisissez d'utiliser spring-data).
- Si les exigences métier évoluent et que votre technologie d'accès aux données n'est pas suffisante pour la prendre en charge (par exemple, vous avez commencé avec JDBC et quelques entités, mais vous avez maintenant besoin d'un modèle de données plus riche et JPA est un meilleur choix), vous devrez modifier l'implémentation de vos DAO, ajoutez quelques annotations sur vos entités et modifiez la configuration du ressort (ajoutez une définition EntityManagerFactory). Le reste de votre code métier ne devrait pas voir d'autres impacts de votre modification.
Remarque: Gestion des transactions
Spring fournit une API pour la gestion des transactions. Si vous prévoyez d'utiliser spring pour l'accès aux données, vous devez également utiliser spring pour la gestion des transactions, car ils s'intègrent très bien ensemble. Pour chaque technologie d'accès aux données prise en charge par spring, il existe un gestionnaire de transactions correspondant pour les transactions locales, ou vous pouvez choisir JTA si vous avez besoin de transactions distribuées. Tous implémentent la même API, de sorte que (encore une fois) le choix de la technologie n'est qu'une question de configuration qui peut être modifiée sans autre impact sur le code métier.
Remarque: documentation Spring
Les liens vers la documentation Spring que vous avez mentionnés sont assez anciens. Voici la documentation de la dernière version (4.1.6, couvrant tous les sujets):
Spring-data ne fait pas partie du framework Spring. Il existe un module commun que vous devez d'abord lire pour vous habituer aux principes. La documentation peut être trouvée ici: