JDBC vs JPA: Pros and Cons

jdbc versus jpa what's the difference why do I need one or the other which one of these do I pick to solve the problem that's in front of me how do I make that kind of choice do I have to go with it all the way or are there options now the land of software development we sure love acronyms our acronyms in the land of java talking to databases there's no shortage there and maybe this has led to some confusion what do I use everyone else is using jpa should I well I heard about spring data jdbc what about spring data jpa right now we're going to talk about jdbc jpa where they came from and the trade-offs that exist now once long ago there was jdbc jdbc is the Java database connectivity API in fact it's one of the J standards that actually is not being affected by Jakarta ee things like servlets JMS soap standards all of those are migrating over to the jakarta.star namespace not jdbc it's part of the jdk in a stain right where it is this is an old standard and it goes all the way back to the days of java 1.1 we're talking 1997. and this API has served as well something to understand is that everything and I mean everything that talks to databases when we're talking about Java technology goes through jdbc and this has its pros and cons basically jdbc is the Java implementation of the standard dance that all Technologies play when they interact with relational databases you open a connection you open a cursor you submit your query you get handed back a result set that you iterate over you then close the result set or the cursor and finally you have to close the connection and you'll find that if you go to just about any technology not just Java based they all kind of have this pattern and maybe you've suffered the fate of implementing 20 queries and forgetting to close one of them and then six weeks later some stack trays erupts about database run out of connections or cursors we track down the issue we patch it we release it into production problem solved and then eight weeks later we find another this is what happens when we're on the hook for managing something that shouldn't be that hard to manage as developers of application code our focus should be write the query get the results the rest of it is kind of a tedious task to manage spring saw this long ago and took note and with one of its most popular coding Solutions the template spring framework released jdbc template it's a template that basically lets you focus on submitting queries and consuming the results all other connection and results that management is handled by the toolkit never again are you going to get that 3am call that your database that the database ran out of connections because you forgot to close a result set you may still get the midnight call but not for that reason the thing is once you've written 200 queries that amount of raw power captured in those strings becomes kind of overwhelming in fact along the way your 13th query against the same you know item object you start to wonder why can't Java see the type that I'm doing and just do it for me why can't Java map the type I mean it's kind of the same thing over and over and over again and this is what spawned the hibernate project the Forerunner of jpa there are two things that we've battled over the years one of them was mapping those table rows to the Java objects as I just mentioned but there's also so something else that lurks in the relational databases and that's the fact that the SQL standards we deal with are to have gaps you go from database to database to database going from MySQL to postgres to Oracle and there's gaps there's holes a query we wrote for MySQL may not work with postgres sometimes the standards can't keep up to what people need so the database vendors add new operations that are definitely not portable do I really need to rewrite my Oracle query when I move to postgres sometimes yes because the ANSI SQL spec doesn't cover all the gaps so database providers fill those gaps hibernate promised us the means to connect job objects together in a unified way if we do the task of mapping our Java objects onto those relational tables now when hibernate started they just used XML files to do this but when Java 5 emerged with annotations that took off like crazy and the world leaped forward at warp speed and while having a neutral way to talk to any database engine on the planet using the same query was really cool there was something else we didn't really understand okay some people saw it coming but most of us did not you never really escape the concept of relational table mapping just because you pick up hibernate and you start using it doesn't mean you actually get to stop thinking about how tables relate to each other how objects different Java types need to be related to each other for the simplest queries yeah you can kind of get away with that but simple queries are the bane of demos and we always run into scenarios where what about this complex app what about this dashboard I need to build that needs to go into 10 different tables to get all the information what if this dashboard is contextual in that you know this part lists up but I need to click on an item to populate this part based on what the operator is doing all these kind of things take us away from the the simple examples and move us in toward complex queries now we got a very long way with hibernate and it even got so popular at one point in time people referred to Spring and hibernate as peanut butter and chocolate it became so popular they standardized it they crafted jpa the Java persistence API we love those acronyms don't we in fact most shops today that are using jpa are using hibernate it's not the only implementation there's other things like Eclipse link but we're going to continue speaking about jpa in general and jpa was so profound you could even say that jpa gave you wings you were able to LEAP past all this fiddly stuff with getting your queries written that you could focus on the business functionality but inevitably we discovered that there's a a deep dark secret in there something lurking under the cover of jpa something that either someone told us or maybe something we assumed on our own this video is sponsored by learning spring boot 3.0 Third Edition Do you want to build a Java app without wasting time do you need to create a web layer backed by a powerful yet intuitive data layer and do you want to protect your users with the most up-to-date and widely used security tools learning spring boot 3.0 Third Edition will show you the way and to top things off it even includes how to deploy and maintain your application in production check it out at springbootlearning.com book and pre-order your copy today as I mentioned you never ever get away from the concept of a relational database tables as you write more complex more entangled more business oriented queries you discover that sometimes your Java objects don't fit that Paradigm you begin to discover You're simply exchanging your knowledge of SQL for your knowledge of jpa it's almost as if you need an equal amount of both you know it's possible in fact it's quite powerful and sometimes that power needs a little assistance hence the creation of spring data jpa spring data jpa can help you with simpler queries and Dodge the need to work too much with JP's entity manager now if you enjoy working with the entity manager have at it if you put spring data jpa into your spring boot project there's actually an entity manager being that you can inject into your service you can pick up the entity manager and you can have at it do all yourself but for a lot of the simpler queries spring data jpa simplifies the process to get it operational up and running into production and then we can move into working on those complex queries eventually something that kind of arises is that you reach a point where you want to get your hands onto those manually written jpql queries and if you believe that you can write a highly detailed complex finely tuned jpql query and then somehow customize the SQL output of it you're in for a rude awakening you see it's a common Paradigm in the olden days to write several dozen queries for your system then through the magic of of the dbas giving you feedback from production and daily experience you can spot what queries are lagging which ones are the most inefficient which ones are hogging the system resources and taking too long and by leveraging things like explain plans you can see how your query was wasting time and then you would attack things by many options you would either create better indexes you have to make sure the statistics are running on your database so the database itself knows how to deal with it you would rewrite certain join statements this is an oldie but goodie you need to stop using uppers or lowers on everything to avoid Full Table scans and don't join the same table 10 times yes I once found a view that did just that and there's a dozen other tactics out there many of them documented in the interwebs the point is you would tune your queries and something that may have taken 20 minutes in the past can be tuned to go sub second and this was par for the course and database application maintenance this is what I've come to dub The Ninth Circle of jpa maybe this is your jam maybe this is cool for you but for many it can be a bad taste in their mouth rewriting jpql queries is kind of different because you're kind of speaking in a higher level language and it still gets translated into actual SQL statements so you don't you're like once removed from what you're really trying to manipulate so can you imagine the enthusiasm when spring data jdbc emerged back in 2017. in fact my teammate jens's talk at the 2018 spring one conference was jammed packed the room was full because I was there sitting in the front row spring data jdbc offers a way to pull back from the edge of the jpa abyss and it's pretty cool so you may want to check it out if you want to understand more spring data jpa attempts to do a lot of the work for you but it doesn't do everything that good old hibernate would do it presumes that if you were to handle a little bit of this yourself you can retain some of the vim and vigor pure jdbc allowed that is writing raw SQL and this is where you now get the ability to see and understand your queries this is where you get the ability to tune SQL statements more to your liking you're able to go in there to specific queries that it's putting together and say uh I need to I need to alter that I'm going to stick my fingers in there and customize this particular query because face it there will always be some amount of tuning that needs to be done to make your queries hum and in exchange for handling a little more on your end you can avoid getting it pulled into potentially the La Brea Tar pit of orms so no matter what you pick jdbc template spring data jpa spring data jdbc hopefully by understanding more about the underlying standards that support them the trade-offs you can make a solid choice about what best fits your needs now if you're head deep in building your repository layer and doing your persistence thing there's one element you need to understand before you hook up that power to the web layer and that's why I want you to go watch this video so you can understand the difference between dtos and entities and when to use them and when not to

Channel: Pro Coder

Views: 22,284

Keywords: spring boot, tutorial, spring boot tutorial, spring data, spring data jpa, spring data tutorial, spring data jpa tutorial, spring boot data jpa, spring boot jpa tutorial, spring boot jpa crud example, spring boot jpa repository tutorial, spring boot jpa hibernate tutorial, spring boot database, spring boot data jpa with h2 database, spring data jdbc, jdbc, jdbctemplate, spring jdbc, spring boot jdbc, spring framework jdbc

Id: XuLUnTlAWmw

Length: 11min 55sec (715 seconds)

Published: Sat Nov 26 2022