Ich bin nicht sicher über Java oder RDB. Grundsätzlich sind wir nicht für den Inhalt verantwortlich.
Ich bin ein Ingenieur, der an der Entwicklung von Webdiensten in Java beteiligt ist, aber wenn ich ein wenig nach Bibliotheken wie ORM recherchiere, die ich gelegentlich verwende (eigentlich verwende ich in meinem Unternehmen nicht viel NoSQL), mehr als ich dachte. Ich bemerkte, dass die Verbindung mit der Datenbank spärlich war, und beschloss, sie zusammenzufassen.
JDBC Zuerst von hier. Eingeführt in JDK 1.1. Eine Standard-API für den Zugriff auf Datenbanken von Java aus. Dieser "Standard" bedeutet, dass es keinen Unterschied zwischen den Anbietern jeder JVM gibt. Da der Zugriff über die folgenden Treiber und Treibermanager erfolgt, unterscheidet sich die JDBC-API nicht zwischen Datenbanken. Es kann gesagt werden, dass der gesamte Mechanismus namens JDBC die Unterschiede zwischen dem JVM-Anbieter und RDB ** absorbiert.
Es ist wie ein Connector, der die JDBC-API für jede Datenbank implementiert. Zum Beispiel gibt es Treiber für MySQL und MariaDB. Wie Sie aus Gugu sehen können, gibt es vier Arten von Verbindungsmethoden, die ich jedoch einmal weglassen werde. Derzeit gilt TYP 4 (ein reiner Java-Treiber) als Mainstream.
Es verwaltet den oben genannten Treiber und spielt die Rolle eines Administrators für die Verbindung von einer Anwendung aus. Wenn der Benutzer es verwendet, geben Sie den JDBC-Treiber für diesen an.
Connection Pooling (CP) Das Verbindungspooling ist in diesem Zusammenhang ein Mechanismus zum Poolen und Wiederverwenden von Verbindungen zwischen Java-Anwendungen und Datenbanken. Ursprünglich ist dies keine programmiersprachenabhängige Story, und das Verbindungsziel ist nicht auf die Datenbank beschränkt. In der Realität bezieht sich das Verbindungspooling jedoch häufig auf die Verbindung zwischen der Anwendung und der Datenbank. Die wichtigste bekannte Methode besteht darin, die an den Anwendungsserver angeschlossene Verbindungspoolbibliothek wie Tomcat oder die dedizierte Bibliothek wie Commons DBCP und HikariCP zu verwenden. ** Ganz einfach ein Wrapper, mit dem Sie JDBC-Verbindungsobjekte wiederverwenden können. ** **. Es gibt zwei Hauptziele von CP (oder besser gesagt, der durch CP erzielte Effekt ist näher).
1 ist, dass das Verbinden und Trennen aus Sicht des Clients eine etwas schwere Verarbeitung ist (es scheint, dass es je nach RDBMS auch auf der Serverseite ist. Es scheint, dass dies jetzt nicht der Fall ist, aber). 2 ist eher zeitweise, wenn bei vielen Verarbeitungen die Datenbank in der Anwendung verwendet wird. Verwenden wir also die Datenbank, die gut ist, und reduzieren Sie die Belastung auf der Serverseite. Ich denke.
Object/Relation Mapper (ORM) Kurz gesagt, eine Bibliothek zum Zuordnen von RDB- "Zeilen" und "Objekten" wie Java. Es scheint einen Diskurs zu geben, dass selbst wenn Sie JDBC verwenden, es sich um ein ORM handelt. Ruhezustand, MyBatis usw. sind bekannt. Da ORM selbst keinen CP-Mechanismus hat, wird es meiner Meinung nach häufig in Kombination mit HikariCP im Ruhezustand verwendet. Während der zuvor erwähnte CP JDBC aus Sicht des Verbindungsmanagements umschließt, kann gesagt werden, dass dies unter dem Gesichtspunkt der Benutzerfreundlichkeit ein Umbruch ist.
Java Persistence API (JPA) Es scheint, dass es ein Framework für die Entwicklung von Anwendungen mit RDB in Java sein soll. Obwohl es sich um eine API handelt, scheint sie sich auch gemeinsam auf Teile wie Metadaten zu beziehen, die die externe Zuordnung beschreiben. Ist es nicht mehr nah an der Implementierung? Ich fühle mich so. Ein weiteres Element ist die Arbeit mit Java-Objekten in einer SQL-ähnlichen Sprache namens JPQL. Es scheint, dass es bis JPA 2.0 ein Teil von Java EE war. JPA im engeren Sinne, dh der Grund, warum die API-Spezifikation angegeben wird. Wenn JDBC jedoch den Unterschied zwischen Datenbanken (genauer gesagt den JDBC-Treibermanager) absorbiert, ist dies ** der Unterschied zwischen ORMs absorbiert **. Der Punkt ist, dass es für Benutzer schwierig ist, verschiedene ORM-Implementierungen zu ersetzen, wenn sie unterschiedliche Spezifikationen haben. Daher sollten wir uns anscheinend für eine gemeinsame API-Spezifikation entscheiden und diese implementieren. Beachten Sie jedoch, dass jedes ORM möglicherweise seine eigenen Funktionen hat und nicht vollständig 1-zu-1 unterstützt wird.
Bekannte Implementierungen umfassen Hibernate ORM und EclipseLink. Abhängig von der Definition von ORM besteht auch die Tendenz, MyBatis usw. als ORM zu klassifizieren. Natürlich ist MyBatis keine ** Implementierung von JPA **.
Spring JDBC https://stackoverflow.com/questions/9469643/difference-between-spring-jdbc-vs-plain-jdbc Nun, ich denke, dies ist auch ein Wrapper, der die Verwendung von JDBC vereinfacht. Es kann ORM genannt werden.
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 Ein ORM, das JPA implementiert, ist weiter verpackt, damit es problemlos aus Spring-Anwendungen verwendet werden kann. Dies ist auch ein Wrapper.
Alles ist abstrahiert, also ist Abstraktion sicherlich schön, aber die Lernkosten werden doch steigen. Computer ist schwierig.
Recommended Posts