Recently I heard one of the 30 years old product has start to replace from JDBC to JOOQ (ORM Tool)!!! Initially it was COBOL command driven application then migrated to great Java.
Today is the first day of the rest of your life.
posted 1 year ago
Tim Moores wrote:There are probably still folks who write JDBC code to handle this, but both JPA and Hibernate are popular (and, IMO, preferable) approaches to ORM.
Tks Tim. I think this should be the direction I have to be heading cos I really find JDBC tough to handle when comes to many to many relationships and as the app get more and more of these relationships, it may get tougher and tougher. Correct me if I am wrong cos I don't have a chance to experience what is the real world java is about.
Can I know if JPA works well with normal Tomcat ? Or must I use Tomcat EE ? cos I know glassfish is expensive when come to hosting....
This many-to-many scenario, when done via JDBC, would tend to reflect the way SQL queries or inserts are carried out against such an arrangement. There would be one (probably two) joins to navigate from the row in one side of the relationship, to its children rows in the other side (traversing the relationship table between). Populating such a table would also look like SQL inserts.
The ORMs make things more convenient, and will probably take less code; you will have fewer "dumb copy" commands to move things out of result sets, when querying. You will not have to call the "insert" method explicitly across all three tables when putting data in.
However to answer the question plainly, I am pretty sure Hibernate will be implemented under the covers, in JDBC. So if you can do it in an ORM, you can do it in JDBC. And I have encountered code written by others on my team that was in JDBC--written only about a year ago, albeit with a less complex scenario.
I Hope it Helps
If a chicken that is half full crosses the road, will anyone hear it?