Les applications d'entreprise traitent souvent des opérations telles que la collecte, le traitement, la transformation et la génération de rapports d'une grande quantité de données. Ces données sont généralement stockées dans un serveur de base de données à un emplacement particulier et récupérées à la demande. L'application est responsable du traitement des données de la base de données et enfin de les présenter à la consommation du client. Mais, les complexités impliquées dans l'atténuation de l'échange de données entre différentes architectures sont le véritable défi auquel les développeurs sont confrontés. Le cœur du problème réside dans l'assouplissement de la relation compliquée du mouvement des données entre le code utilisé pour développer l'application et le modèle de stockage utilisé pour la persistance des données. En bref, l'idée est de créer un mécanisme d'interaction transparente entre deux modèles inflexibles :la nature orientée objet du langage Java et le modèle de base de données relationnelle.
API de base pour les bases de données
La plate-forme Java dispose déjà d'API standard pour travailler avec des systèmes de base de données sous la forme d'API JDBC. Ces API sont excellentes pour travailler avec la base de données et fournissent les moyens nécessaires pour interagir avec la base de données de manière pratique à partir du langage Java. Mais le problème est que Java est un langage orienté objet. Le JDBC fournit des API de base pour l'interaction avec la base de données et ne se concentre pas sur la transformation de la structure des lignes et des colonnes de la table de la base de données en une classe d'entité. Par conséquent, une couche d'API est recherchée qui fonctionne au-dessus de l'API JDBC. L'API de persistance, ou JPA, atténue deux modèles architecturaux différents dans le but de tirer parti de la fluidité de fonctionnement. L'API aide à représenter une table de relations de base de données en tant que POJO et peut être traitée de la même manière tout au long du code Java. L'API JDBC principale fonctionne en arrière-plan pour gérer les subtilités de la communication et de la connexion à la base de données, tandis que JPA permet d'effectuer les transactions conformément au code orienté objet du langage Java. Cependant, le mappage des données entre la base de données relationnelle et Java n'est pas une tâche facile.
Prise en charge de la persistance Java
Dans une base de données relationnelle typique, les informations sont stockées dans une structure de lignes et de colonnes. L'échange de données entre un système de base de données et le modèle objet de l'application Java est difficile car Java désigne une seule entité comme une classe désignée par un ensemble de propriétés et d'opérations qui leur sont appliquées. Par conséquent, pour conformer une inadéquation comportementale entre les deux architectures différentes, un programmeur Java doit écrire de nombreuses lignes de code. Ces lignes de code aident à transformer les données de ligne et de colonne de la table de base de données en objets Java. Mais, souvent, ces lignes de code deviennent trop répétitives, ce qui se traduit par un code source rempli de codes passe-partout. Ceci n'est pas souhaitable et viole le principe de réutilisation orienté objet de base. Bien que des codes intelligents puissent atténuer une grande partie de l'adversité, ce n'est pas une solution facile. L'émergence de solutions tierces est un répit dans le mappage des données de base de données en objets Java, mais elles n'étaient pas standard. La mise en œuvre de chaque fournisseur variait considérablement d'une autre. Tout cela signifie que la situation exigeait une bibliothèque d'API de persistance standard de la plate-forme Java elle-même. Cela a conduit à l'introduction de Java Persistence API (JPA), en particulier pour combler le fossé entre le modèle de domaine orienté objet de Java et le système de base de données.
Solutions propriétaires
Comprenez que les solutions relationnelles objet existent depuis un certain temps, remontant même avant la naissance du langage Java lui-même. Par exemple, le produit TopLink d'Oracle a en fait démarré avec Smalltalk, puis est ensuite passé à Java. Aujourd'hui, il fait partie des serveurs OracleAS, WebLogic et OC4J. En fait, les deux API de persistance les plus populaires étaient TopLink d'Oracle, une norme propriétaire dans le domaine commercial, et Hibernate dans le domaine de la communauté open source. Plus tard, Hibernate est devenu plus populaire et a fortement influencé la création de la bibliothèque JPA standard.
Mappeurs de données
Un mappeur de données est essentiellement un modèle architectural proposé par Martin Fowler dans son livre Patterns of Enterprise Application Architecture , 2003. Il fournit un moyen partiel d'aborder le problème objet-relationnel. Le mappeur aide à créer une stratégie qui tombe dans la catégorie entre JDBC simple et une solution de mappage relationnel d'objets entièrement fonctionnelle. Ici, les développeurs d'applications créent une chaîne SQL brute pour mapper des tables de base de données à des objets Java à l'aide de la méthode de mappage de données. Il existe un framework populaire qui utilise cette technique de mappage entre la base de données SQL et l'objet Java, appelé Apache iBatis. Le projet Apache iBatis a été déclaré inactif maintenant. Cependant, les créateurs originaux d'Apache iBatis ont transféré le projet à MyBatis et sont en cours de développement.
Contrairement à d'autres solutions de problèmes relationnels objet utilisant le cadre des mappeurs de données comme MyBatis, nous pouvons avoir un contrôle complet sur les transactions SQL avec la base de données. C'est une solution légère et ne supporte pas les frais généraux d'un cadre ORM complet. Mais, il y a un problème avec les mappeurs de données. Toute modification apportée au modèle objet a des répercussions sur le modèle de données. Il faut apporter des modifications importantes aux instructions SQL directement en conséquence. La nature minimaliste du framework aide les développeurs à intégrer de nouveaux changements et modifications en fonction des besoins. Les mappeurs de données sont particulièrement utiles dans une situation où nous avons besoin d'un cadre minimal, d'une gestion SQL explicite et d'un contrôle accru pour les modifications apportées par le développeur.
JDBC
Le JDBC (Java Database Connectivity) est une version spécifique à Java de la spécification ODBC (Object Database Connectivity) de Microsoft. L'ODBC est une norme permettant de connecter n'importe quelle base de données relationnelle à partir de n'importe quel langage ou plate-forme. JDBC fournit une abstraction similaire par rapport au langage Java. JDBC utilise SQL pour interagir avec la base de données. Les développeurs doivent écrire des requêtes DDL ou DML conformément à la spécification syntaxique de la base de données principale, mais les traiter à l'aide du modèle de programmation Java. Il existe un couplage étroit entre la source Java et les instructions SQL. Nous pouvons recourir à des instructions SQL brutes et les manipuler statiquement en fonction des besoins. En raison de sa nature statique, il est difficile d'intégrer des changements. De plus, les dialectes SQL varient d'un fournisseur de bases de données à l'autre. JDBC est câblé à la base de données et non au modèle objet du langage Java. Par conséquent, il devient rapidement fastidieux de travailler avec, en particulier lorsque l'interaction de la base de données à partir du code source Java augmente. Cependant, JDBC est le principal support pour la persistance de la base de données en Java et constitue la base des frameworks de haut niveau.
EJB
L'Enterprise Java Bean (EJB) avec J2EE a apporté de nouveaux changements dans le domaine de la persistance Java sous la forme du bean entité. L'idée était d'empêcher les développeurs d'intervenir directement dans les subtilités de la persistance des bases de données. Il a introduit une approche basée sur l'interface. Il existe un compilateur de bean spécialisé pour générer l'implémentation de la persistance, de la gestion des transactions et de la délégation de la logique métier. Des descripteurs de déploiement XML spécialisés ont été utilisés pour configurer les beans entité. Le problème est que les EJB, plutôt que de simplifier les choses, ont incorporé beaucoup de complexité. En conséquence, malgré de nombreuses améliorations ultérieures telles que l'introduction du langage de requête Enterprise JavaBeans (EJB QL), il a rapidement perdu de sa popularité.
Objet de données Java
Le JDO (Java Data Object) a tenté de résoudre le problème rencontré par le modèle de persistance EJB. Il fournit une API pour une persistance transparente et est conçu pour fonctionner avec EJB et J2EE. JDO est un produit fortement influencé et pris en charge par les bases de données orientées objet. Les objets de persistance sont des objets Java simples qui ne nécessitent pas qu'un développeur implémente une classe ou une interface spéciale. Les spécifications de persistance des objets sont généralement définies dans un métafichier XML. Les langages de requête pris en charge sont orientés objet par nature. Malgré de nombreuses fonctionnalités intéressantes, la spécification JDO n'a pas été largement acceptée par la communauté des développeurs.
API de persistance Java
Il existait un certain nombre de cadres de persistance propriétaires à la fois dans le domaine commercial et dans le domaine open source. Des frameworks tels que Hibernate et TopLink semblaient répondre assez bien aux besoins de l'application. En conséquence, Hibernate a été choisi comme base principale pour créer un modèle de persistance standard appelé JPA.
JPA est un framework de persistance Java léger standard qui permet de créer un mappage relationnel d'objet à l'aide de POJO. JPA aide également à intégrer la persistance dans une application d'entreprise évolutive. Il est facile à utiliser car il n'y a qu'un petit nombre de classes qui doivent être exposées à une application intéressée par l'utilisation du modèle de persistance JPA. L'utilisation d'un POJO est peut-être l'aspect le plus intrigant de JPA. Cela signifie qu'il n'y a rien de spécial dans l'objet; qui le rend persistant. Le mappage objet-relationnel est piloté par les métadonnées. Cela peut être fait en utilisant des annotations en interne dans le code ou en externe. en utilisant XML.
Les API persistantes de JPA existent en tant que couche distincte de l'objet persistant. La logique métier appelle généralement l'API et transmet l'objet persistant pour qu'il agisse dessus. Bien que l'application soit consciente de l'API persistante, l'objet persistant, étant POJO, ignore complètement sa capacité de persistance.
Conclusion
Cet article a donné un aperçu de certaines des solutions propriétaires disponibles avant l'introduction de JPA, telles que le mappeur de données, JDBC et EJB. L'idée est de donner un aperçu de ce qui a conduit à la création de JPA, et un peu de la technique persistante de son prédécesseur. Restez à l'écoute; les articles suivants approfondissent des aspects plus spécifiques de l'API JPA.
