I'm not confident about Java or RDB. Basically, we are not responsible for the content.
I'm an engineer involved in developing web services in Java, but when I'm doing a little research on libraries such as ORM that I use casually (actually, I don't use a lot of NoSQL in my business), more than I thought. I noticed that the connection with the database was sparse, so I decided to summarize it.
JDBC First from here. Introduced in JDK 1.1. A standard API for accessing databases from Java. This "standard" means that there is no difference between the vendors of each JVM. Since it is accessed through the following drivers and driver managers, the JDBC API does not differ between databases. It can be said that the entire mechanism called JDBC absorbs the differences between the JVM vendor and RDB **.
It's like a connector that actually implements the JDBC API for each database. For example, there are drivers for MySQL and MariaDB. As you can see from Gugu, there are four types of connection methods, but I will omit them once. Currently, TYPE 4 (Pure Java driver) is considered to be the mainstream.
It manages the above driver and plays the role of an administrator for connecting from the application. If the user uses it, specify the JDBC driver for this one.
Connection Pooling (CP) Connection pooling in this context is a mechanism for pooling and reusing connections between Java applications and databases. Originally, this is not a programming language-dependent story, and the connection destination is not limited to the database, but I think that connection pooling actually refers to the connection between the application and the database. The main known method is to use the connection pooling library attached to the application server such as Tomcat, or the dedicated library such as Commons DBCP and HikariCP. ** Very simply, a wrapper that allows you to reuse JDBC Connection objects. ** ** There are two main purposes of CP (or rather, the effect obtained by CP is closer).
1 is that connecting and disconnecting from the client's point of view is a bit heavy processing (it seems that it is also on the server side depending on the RDBMS. It seems that it is not the case now, but). 2 is rather intermittent when a lot of processing uses the database in the application, so let's use a good one and reduce the load on the server side. I think.
Object/Relation Mapper (ORM) In short, a library for mapping RDB "rows" and "objects" such as Java. There seems to be a discourse that even if you use JDBC, it is an ORM. Hibernate, MyBatis, etc. are known. Since ORM itself does not have a CP mechanism, I think that it is often used in combination with hibernate-HikariCP. Whereas CP wraps JDBC from a connection management perspective, this is ** wrapping from a usability aspect **.
Java Persistence API (JPA) It seems that it is supposed to be a framework for developing applications using RDB in Java. Although it is an API, it seems that it also collectively refers to parts such as metadata that externally describes mapping. Isn't it close to implementation anymore? I feel like that. Another element is working with Java objects in a SQL-like language called JPQL. It seems that it was a part of Java EE until JPA 2.0. JPA in the narrow sense, that is, the reason why the API specification is specified, but if JDBC absorbs the difference between databases (to be exact, the JDBC driver manager), this is ** absorb the difference between ORMs **. The point is that if various ORM implementations have various specifications, it is difficult for users to replace them, so it seems that we should decide on a common API specification and implement it. However, note that each ORM may have its own functionality and is not fully 1-on-1 supported.
Well-known implementations include Hibernate ORM and EclipseLink. Depending on the definition of ORM, there is also a tendency to classify MyBatis etc. as ORM. Of course, MyBatis is not an implementation of JPA **.
Spring JDBC https://stackoverflow.com/questions/9469643/difference-between-spring-jdbc-vs-plain-jdbc Well, I think this is also a wrapper that makes JDBC easier to use. It may be called 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 An ORM that implements JPA is further wrapped so that it can be easily used from Spring applications. This is also a rapper.
Everything is abstracted, so abstraction is certainly beautiful, but the learning cost will rise after all. Computer is difficult.
Recommended Posts