web-dev-qa-db-fra.com

Spring DAO vs Spring ORM vs Spring JDBC

Je passais en revue les technologies d’accès aux données supportées par Spring, et j’ai remarqué qu’il mentionnait plusieurs options et je ne suis pas sûr de la différence entre elles:

Si je comprends bien, Spring JDBC fournit des modèles permettant de réduire le code standard afin d’accéder à une base de données de manière très simple: vous écrivez vos propres requêtes SQL.

Spring-ORM fournit des modèles simplifiés pour accéder aux bases de données via des technologies ORM, telles que Hibernate, My (i) Batis, etc.

Spring-DAO selon le site Web de Spring:

La prise en charge de DAO (Data Access Object) au printemps a pour but de le rendre facile à utiliser avec les technologies d'accès aux données telles que JDBC, Hibernate ou JDO de manière cohérente

Je suis un peu clair sur ORM vs JDBC, car ils visent différentes manières d'accéder à la base de données. Mais Spring-DAO est tout simplement déroutant! 

Quelqu'un pourrait-il clarifier quelles sont exactement les différences entre ces trois? Quelles sont les situations à privilégier?

De plus, il existe un autre projet Spring-DATA également disponible ( http://projects.spring.io/spring-data/ ) Maintenant, s’agit-il d’un projet parent pour tous les techniciens d’accès aux données pris en charge par Spring ou est-ce juste? un nouveau nom pour Spring-DAO?

springspring-dataspring-jdbcspring-orm
88
Pat

Voici une introduction à chaque technologie mentionnée.

Spring-DAO

Spring-DAO n’est pas stricto senso un module printanier, mais plutôt des conventions qui devraient vous obliger à écrire DAO et à 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, annotez-le avec @Repository afin que les exceptions liées à la technologie sous-jacente (JDBC, Hibernate, JPA, etc.) soient systématiquement traduites dans la sous-classe DataAccessException appropriée.

Par exemple, supposons que vous utilisiez maintenant Hibernate et que votre couche de service contienne HibernateException afin de pouvoir y réagir. Si vous passez à JPA, vos interfaces DAO ne doivent pas changer et la couche de service sera toujours compilée avec des blocs capturés HibernateException, mais vous ne les entrerez jamais car vos DAO lançent 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 de technologie de persistance, la même variable Printemps DataAccessExceptions sera toujours émise, car spring aura traduit les exceptions natives.

Notez toutefois que son utilisation est limitée pour les raisons suivantes:

  1. 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 poursuivre l'exécution avec un autre chemin.
  2. La hiérarchie des exceptions est généralement plus riche dans votre fournisseur que ce que Spring fournit, et il n’ya pas de mappage définitif d’un fournisseur à l’autre. S'en remettre à cette règle est dangereux ..__ Ceci est toutefois une bonne idée d'annoter vos DAO avec @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 SQL et ses paramètres. Vous avez juste besoin de le configurer avec une 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 support JdbcDaoSupport, que vous pouvez étendre pour développer votre DAO. Il définit en gros 2 propriétés: un DataSource et un JdbcTemplate qui peuvent être utilisés pour implémenter les méthodes DAO. Il fournit également un traducteur d'exceptions à partir des exceptions SQL pour print DataAccessExceptions.

Si vous envisagez d’utiliser plain jdbc, c’est le module que vous devrez utiliser.

Spring-ORM

Spring-ORM est un module parapluie couvrant de nombreuses technologies de persistance, notamment JPA, JDO, Hibernate et iBatis. Spring fournit des classes d'intégration pour chacune de ces technologies, de sorte que chaque technologie puisse être utilisée conformément aux principes de configuration de Spring et s'intègre de manière fluide à la gestion des transactions de Spring.

Pour chaque technologie, la configuration consiste essentiellement à injecter un bean DataSource dans une sorte de bean SessionFactory ou EntityManagerFactory etc. Pour JDBC pur, de telles classes d'intégration ne sont pas nécessaires (à part JdbcTemplate), car JDBC ne s'appuie que sur un DataSource.

Si vous envisagez 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 cadre qui fournit une API commune pour définir le mode d'accès aux données (annotations DAO +) de manière plus générique, couvrant à la fois les sources de données SQL et NOSQL.

L’idée de départ est de fournir une technologie permettant au développeur d’écrire l’interface pour une DAO (méthodes Finder) et les classes d’entités d’une manière indépendante de la technologie et, en fonction de la configuration uniquement (annotations sur les DAO et les entités + configuration de ressort, que ce soit). xml ou Java), décide de la technologie d'implémentation, qu'il s'agisse de JPA (SQL), de Redis, d'Hadoop, etc. (NOSQL). 

Si vous suivez les conventions de dénomination définies par spring pour les noms de méthodes du Finder, vous n'avez même pas besoin de fournir les chaînes de requête correspondant aux méthodes du Finder pour les cas les plus simples. Dans d'autres situations, vous devez fournir la chaîne de requête à l'intérieur des annotations sur les méthodes du Finder.

Lorsque le contexte de l'application est chargé, spring fournit des proxy pour les interfaces DAO, contenant tout le code standard associé à 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 est qu'il n'est pas nécessaire de faire un choix définitif pour la technologie. C'est en fait là que réside Spring power: en tant que développeur, vous vous concentrez sur votre activité lorsque vous écrivez du code. Si vous le faites bien, le changement de 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é et les champs en fonction de la technologie, mais pour l’instant, les POJO sont suffisants pour commencer. Concentrez-vous simplement sur les besoins de votre entreprise.

  1. Sur cette base, quelqu'un d'autre peut commencer à travailler sur la couche de services, avec des simulacres pour vos DAO.
  2. Vous apprendrez les différentes technologies de persistance (sql, no-sql) pour trouver la solution la mieux adaptée à vos besoins et vous en choisirez une. 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 des données de printemps).
  3. Si les besoins de l'entreprise évoluent et que votre technologie d'accès aux données ne suffit pas (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 la mise en œuvre. de vos DAO, ajoutez quelques annotations sur vos entités et modifiez la configuration de ressort (ajoutez une définition EntityManagerFactory). Le reste de votre code d'entreprise ne devrait pas voir d'autres impacts de votre modification.
  4. Remarque: Gestion des transactions.
  5. Spring fournit une API pour la gestion des transactions. Si vous prévoyez d’utiliser Spring pour l’accès aux données, utilisez-le également pour la gestion des transactions, car elles s’intègrent parfaitement. Pour chaque technologie d'accès aux données prise en charge par Spring, il existe un gestionnaire de transactions correspondant aux transactions locales. Vous pouvez également choisir JTA si vous avez besoin de transactions distribuées. Toutes implémentent la même API, de sorte que le choix de la technologie (une fois de plus) est simplement une question de configuration qui peut être modifiée sans impact supplémentaire sur le code métier.

Remarque: documentation Spring

Les liens vers la documentation de Spring que vous avez mentionnés sont plutôt anciens. Voici la documentation de la dernière version (4.1.6, couvrant tous les sujets):.

Page html unique: http://docs.spring.io/spring/docs/current/spring-framework-reference/htmlsingle/

  • 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:

Une seule page html: http://docs.spring.io/spring-data/data-commons/docs/1.9.2.RELEASE/reference/html/

144
Gaetan

Vous créez une interface telle que SomeObjectDao, puis vous créez différentes implémentations de cette interface, telles que JdbcSomeObjectDao, HibernateSomeObjectDao. Ensuite, dans votre classe SomeObjectService, vous utiliserez l'interface SomeObjectDao et y injecterez l'une des implémentations concrètes. Ainsi, chaque implémentation de SomeObjectDao masquera les détails, que vous utilisiez JDBC, ORM, etc.

En général, JDBC et différentes implémentations de ORM génèrent différents types d'exceptions. Le support DAO de Spring peut mapper ces différentes exceptions, propres à une technologie, aux exceptions communes de DAO de Spring. Vous êtes donc davantage découplé de la mise en œuvre réelle. De plus, le support DAO de Spring offre un ensemble de classes abstraites *DataSupport qui aident encore plus au développement DAO. Donc, en plus de l'implémentation de votre interface SomeObjectDao, vous pouvez étendre l'une des classes *DataSupport de Spring.

0
mike_m

La librairie spring-dao s'est arrêtée dans la version 2.0.8 (janvier 2008). Les cours de spring-dao ont été copiés dans spring-tx. Donc, si vous avez besoin d’une classe que vous trouvez dans spring-dao, ajoutez la dépendance à spring-tx à la place. ( La source .)

0
Paulo Merson

Comme information supplémentaire. Je vous suggère d'utiliser Spring Data JPA. Utiliser des annotations telles que: @Repository, @Service. Je vous montre un exemple:

@Repository("customerEntitlementsRepository")
public interface CustomerEntitlementsRepository extends CrudRepository<BbsExerul, BbsExerulPK> {

  @Query(value = "SELECT " + "CONTRACT_NUMBER, EXECUTIVE_NUMBER, " + "GROUP_VALUE, " + "CODE, "
      + "SUBCODE, " + "CURRENCY " + "FROM BBS_EXERUL " + "WHERE CONTRACT_NUMBER =:clientId AND "
      + "EXECUTIVE_NUMBER =:representativeId", nativeQuery = true)
  Collection<CustomerEntitlementsProjection> getFieldsExerul(@Param("clientId") String clientId,
      @Param("representativeId") String representativeId);

}

Où CustomerEntitlementsProjection est une projection de printemps, liée à votre entité ou à un objet DTO;

@Projection(name = "customerEntitlementsProjection", types = { BbsExerul.class })
public interface CustomerEntitlementsProjection {

  String getContractNumber();

  String getExecutiveNumber();
0
Brandon Osorio