After 15 posts, it is time for this tutorial series to move on from Servlets (and related technologies) in order to cover another part of the Java EE stack - the Java Persistence API, or JPA.
Before we discuss the what and the why of JPA, let’s talk a little about JDBC.
JDBC
If you write Java code for long enough, you’ll find yourself using JDBC sooner or later. And for good reason; it is easy to configure without having to pull down tons of dependencies, and low level enough that you can make it do whatever you want.
That being said, when you find yourself working on a large, database-intensive application, JDBC starts to show its limits. For instance, it would require you to write and manage a ton of hand written SQL statements, and since each database has a slightly different SQL syntax, these statements won’t be portable if you ever switch DB’s.
Additionally, if your database rows are large and complex, you will have to pick through the ResultSet
objects returned by JDBC to extract for each column one by one. In short, JDBC is nice to have around, but for certain situations it is more trouble than it is worth.