Je ne suis pas sûr de Java ou de RDB. Fondamentalement, nous ne sommes pas responsables du contenu.
Je suis un ingénieur impliqué dans le développement de services Web en Java, mais quand je fais un peu de recherche sur des bibliothèques telles que ORM que j'utilise avec désinvolture (en fait, je n'utilise pas beaucoup NoSQL dans mon entreprise), plus que je ne le pensais. J'ai remarqué que la connexion avec la base de données était clairsemée, j'ai donc décidé de la résumer.
JDBC D'abord d'ici. Introduit dans JDK 1.1. Une API standard pour accéder aux bases de données depuis Java. Ce «standard» signifie qu'il n'y a aucune différence entre les fournisseurs de chaque JVM. Puisqu'il est accessible via les pilotes et gestionnaires de pilotes suivants, l'API JDBC ne diffère pas entre les bases de données. On peut dire que l'ensemble du mécanisme appelé JDBC absorbe les différences entre le fournisseur JVM et RDB **.
C'est comme un connecteur qui implémente réellement l'API JDBC pour chaque base de données. Par exemple, il existe des pilotes pour MySQL et MariaDB. Comme vous pouvez le voir sur Gugu, il existe quatre types de méthodes de connexion, mais je les omettrai une fois. Actuellement, TYPE 4 (un pilote Java pur) est considéré comme le courant dominant.
Il gère le pilote ci-dessus et joue le rôle d'un administrateur pour se connecter depuis une application. Si l'utilisateur l'utilise, spécifiez le pilote JDBC pour celui-ci.
Connection Pooling (CP) Le regroupement de connexions dans ce contexte est un mécanisme de regroupement et de réutilisation des connexions entre les applications Java et les bases de données. À l'origine, il ne s'agit pas d'une histoire dépendante du langage de programmation et la destination de la connexion ne se limite pas à la base de données, mais en réalité, le regroupement de connexions fait souvent référence à la connexion entre l'application et la base de données. La principale méthode connue consiste à utiliser la bibliothèque de regroupement de connexions attachée au serveur d'application tel que Tomcat, ou la bibliothèque dédiée telle que Commons DBCP et HikariCP. ** Très simplement, un wrapper qui vous permet de réutiliser des objets JDBC Connection. ** ** Il y a deux objectifs principaux de CP (ou plutôt, l'effet obtenu par CP est plus proche).
1 est que se connecter et se déconnecter du point de vue du client est un traitement un peu lourd (il semble que c'est aussi du côté serveur en fonction du SGBDR. Il semble que ce ne soit pas le cas maintenant, mais). 2 est plutôt intermittent lorsque beaucoup de traitement utilise la base de données dans l'application, alors utilisons celle qui est bonne et réduisons la charge côté serveur. Je pense.
Object/Relation Mapper (ORM) En bref, une bibliothèque pour mapper des "lignes" et des "objets" RDB comme Java. Il semble y avoir un discours selon lequel même si vous utilisez JDBC, c'est un ORM. Hibernate, MyBatis, etc. sont connus. Puisque l'ORM lui-même n'a pas de mécanisme CP, je pense qu'il est souvent utilisé en combinaison avec hibernate-HikariCP. Alors que CP enveloppe JDBC du point de vue de la gestion des connexions, on peut dire qu'il s'agit de ** wrapping du point de vue de l'utilisabilité **.
Java Persistence API (JPA) Il semble que ce soit censé être un framework pour développer des applications utilisant RDB en Java. Bien qu'il s'agisse d'une API, il semble qu'elle se réfère également collectivement à des parties telles que les métadonnées qui décrivent le mappage en externe. N'est-il plus proche de la mise en œuvre? Je me sens comme ça. Un autre élément consiste à travailler avec des objets Java dans un langage de type SQL appelé JPQL. Il semble qu'il faisait partie de Java EE jusqu'à JPA 2.0. JPA au sens strict, c'est-à-dire la raison pour laquelle la spécification d'API est spécifiée, mais si JDBC absorbe la différence entre les bases de données (pour être exact, le gestionnaire de pilotes JDBC), c'est ** absorbe la différence entre les ORM **. Le fait est que si diverses implémentations ORM ont des spécifications différentes, il est difficile pour les utilisateurs de les remplacer, il semble donc que nous devrions décider d'une spécification API commune et l'implémenter. Cependant, notez que chaque ORM peut avoir ses propres fonctionnalités et n'est pas entièrement pris en charge 1-on-1.
Les implémentations bien connues incluent Hibernate ORM et EclipseLink. En fonction de la définition d'ORM, il y a aussi une tendance à classer MyBatis etc. comme ORM. Bien sûr, MyBatis n'est pas une ** implémentation de JPA **.
Spring JDBC https://stackoverflow.com/questions/9469643/difference-between-spring-jdbc-vs-plain-jdbc Eh bien, je pense que c'est aussi un wrapper qui rend JDBC plus facile à utiliser. Il peut être appelé ORM.
Spring Data JPA https://stackoverflow.com/questions/16148188/spring-data-jpa-versus-jpa-whats-the-difference https://stackoverflow.com/questions/42470060/spring-data-jdbc-spring-data-jpa-vs-hibernate Un ORM qui implémente JPA est encapsulé de manière à pouvoir être facilement utilisé à partir d'applications Spring. C'est aussi un emballage.
Tout est abstrait, donc l'abstraction est certainement belle, mais le coût d'apprentissage augmentera après tout. L'ordinateur est difficile.
Recommended Posts