Pattern for working with different database dialects via JDBC - java

I'm creating an application that has to work with different databases (Oracle, MSSQL, MySQL...) through JDBC. I have to work via JDBC because my application calls stored procedures in these databases.
What is the best aproach for building such applications? Are there any frameworks for this?
Important: The solution must nicely deal with Spring Framework.
I am thinking about Hibernate, since it is robust ORM solution and it has a buildin support for stored procedures: http://docs.jboss.org/hibernate/stable/core/reference/en/html_single/#sp_query
Please, provide me with your oppinions about my current choise.
Best regards,
Max

I would give myBatis a good look. It handles all the pain associated with JDBC and transactions and mapping resultsets to Java objects or hashes.
It also plays nice with SQL and stored procedure by separating them from the Java code and configuring them in XML configuration files. This works in practice a lot better because it is easier to copy queries from XML to an interactive SQL browser and vice versa.
To connect to multiple datasets you need to create an SqlSessionFactory for each datasource.

Hibernate is usually the standard option (and the one I'd choose). I prefer using JPA over Hibernate, but that's not an option if you need Stored Procedures. But regarding the comment about iBatis:
While I have no experience with iBatis myself, it seems the Spring Support for iBatis is not bad:
From the Spring Reference, chapter 13.6: iBATIS SQL Maps:
The iBATIS support in the Spring
Framework much resembles the JDBC
support in that it supports the same
template style programming, and as
with JDBC and other ORM technologies,
the iBATIS support works with Spring's
exception hierarchy and lets you enjoy
Spring's IoC features.
Transaction management can be handled
through Spring's standard facilities.
No special transaction strategies are
necessary for iBATIS, because no
special transactional resource
involved other than a JDBC Connection.
Hence, Spring's standard JDBC
DataSourceTransactionManager or
JtaTransactionManager are perfectly
sufficient.

Related

Use of Spring data JPA with maven in Eclipse

I'm new with Spring and I would like to use Spring Data with Jpa, Maven and Mysql in Eclipse environment. Then I'm going to use Tomcat as application server
I read a lot of tutorial but all of them are different from each other therefore don't understand what I have really to do. At the moment I'm confusing between these technology and DAO/DAL structure
Must I use Hibernate?
I have to use it with java JPA and then I have to add Spring data?
If anyone has an example or a tutorial I thank him.
Official spring data link
For spring-data-jpa,maven,mysql,hibernate,eclipse example tutorial
Hibernate is optional, it depends on your use case what you want to do. Its a ORM for mapping your db tables into java objects and have lot of other features like session caching, second level caching, criteria queries, validation, search/filters etc.
If you are just testing queries to load data you can use spring jpa queries directly, you will find examples in spring-data-jpa link

JDBCTemplate for JavaEE and CDI

I am working on a JavaEE7/CDI project that makes heavy use of pure JDBC code.
Is there a library that could help me eliminate the boilerplate code, much like what JDBCTemplate does for Spring. Obviously adding Spring as dependency is not an option.
I would suggest the Apache commons-dbutils, which is a light library for JDBC operations. It provides the QueryRunner class that seems very similar to Spring's JDBCTemplate.
I would look into MyBatis (formerly iBatis).
MyBatis is a first class persistence framework with support for custom SQL, stored procedures and advanced mappings. MyBatis eliminates almost all of the JDBC code and manual setting of parameters and retrieval of results. MyBatis can use simple XML or Annotations for configuration and map primitives, Map interfaces and Java POJOs (Plain Old Java Objects) to database records.

Relationships between Spring, Hibernate, JDBC

I just start reading Sun's JDBC tutorial. I installed MySQL Connector/J and was just skimming through its menu, then came across this statement:
"Although JDBC is useful by itself, we would hope that if you are not familiar with JDBC that after reading the first few sections of this
manual, that you would avoid using naked JDBC for all but the most trivial problems and consider using one of the popular persistence
frameworks such as Hibernate, Spring's JDBC templates or Ibatis SQL Maps to do the majority of repetitive work and heavier lifting that is sometimes required with JDBC"
So what are the relationships between Spring, Hibernate, JDBC? What does the statement mean by saying "avoid using naked JDBC"?
Thanks,
Sarah
If you use Hibernate, Spring's JDBC templates or Ibatis SQL Maps, you're still using JDBC, but you don't have to deal with it directly. They're doing it for you, and to a degree, insulate you from some difficulties in the use of JDBC.
Hibernate is an object-relational-mapping framework.
MyBatis, formerly known as iBatis, is a data mapping framework.
Spring is a wide-ranging set of web framework components, and includes templating subsystems that allow integration with JDBC, Hibernate, or iBatis and abstract away some of the details of dealing with any of them.
You should indeed learn JDBC, but also (eventually) learn some of these others and try to avoid using JDBC directly for anything very complex.
These ideas are also (especially Hibernate) closely related to the Java Persistence API (JPA), which is also certainly worth learning.
You might also want to look at Java Data Objects (JDO).
Don't try to learn it all at once, though.
Starting with JDBC is a good idea. Staying with it is not.
Alphabets > Words > Sentences.
That is how we learn (natural) language.
Similarly, I see:
JDBC API > JDBC API with Connection Pooling > Spring JDBC Template > ORM/JPA/JDO
"avoid using naked JDBC" - Don't use the JDBC API directly.
Hibernate - A database persistence framework. It lets you store Java objects in databases. Pretty nifty.
Spring - It's actually a web development framework. The JDBC templates are an abstraction to JDBC, I think.

Can I and should I use Eclipselink for non OR database interactions?

We are using Eclipselink for ORM, but we have a need for some more lightweight database interactions that are more equivalent to JDBC. My question is whether Eclipselink supports such an idiom and whether there are any advantages of it to straight JDBC. I can see one advantage being consistency and being able to use the existing connection handling. Others?
Specifically, what I'm looking for is something equivalent to Hibernate's Native SQL Query.
If you are using both JPQL and SQL queries in your application then JPA 2 native queries are probably the right approach. Here are some examples :
http://www.oracle.com/technology/pub/articles/vasiliev-jpql.html
If your app only uses SQL queries and updates, then ORM is just an overhead. You can get declarative transactions also differently, for example via Spring's JDBC support.
EclipseLink implements JPA - you can run SQL queries via an EntityManager. If you start running SQL queries not related to the model of your application you'll have no advantages over JDBC - on the contrary you'll be using a much heavier infrastructure. If you tie the SQL to the model however you'll have the advantage of making additional optimizations to queries utilizing the full db potential. I'm not sure if that's what you want to do however...

Spring vs Hibernate

Just trying to get my head round Spring and figuring out how I wire up an Oracle connection in xml config file, and now find out I need yet another framework! - Hibernate, this is soooo frustrating as it feels like I'm getting deeper and deeper into more and more frameworks without actually getting what I need done!
I looked at Hibernate and it seems to do similar things to Spring, bearing in mind I just want to do some SQL inserts in Oracle.
I am reluctant and do not have time to learn 2 frameworks - could I get away with just adopting Hibernate for the simple things I need to do?
...could I get away with just adopting Hibernate for the simple things I need to do?
Yes
Hibernate is for ORM ( object relational mapping ) that is, make your objects persistent to a RDBMS.
Spring goes further. It may be used also as a AOP, Dependency Injector, a Web Application and ORM among other things.
So if you only need ORM, just use Hibernate. Time will come when you need Spring, and you will learn it then.
Here's an architectural view of Spring:
And this is Hibernate:
Spring and Hibernate are totally different frameworks for different problems. Spring is a huge framework with many many features, Hibernate is an O/R bridge.
I would recommend using plain old JDBC in your case ('just some SQL inserts in Oracle').
You could get away with using just spring and spring-JDBC integration. Depending on the complexity of your data-access needs it may be more than enough. The spring Object-relation mapping is also worth looking into if you're going to do a lot of data-access.
The nice thing about spring is that it's a very loosely coupled framework. So you can read up on the bits you use, and forget the rest - even in the runtime.
Spring and Hibernate are really intended to do two different things. Spring is first and foremost an inversion-of-control container and configuration subsystem, while Hibernate is a database binding and lazy loading engine. If you don't want to introduce a bunch of new stuff into your code, stick with Spring and roll your own queries or use iBatis to do much simpler database binding.
If all you want is insert sql for oracle I would stick to a simple JDBC library. All you need is a Connection and maybe some ConnectionPool (maybe c3po). Hibernate and the like are too big/too complicated and IMO inferior. Hibernate incorporates JDBC under the hood but in every measurable way is inferior -- harder to use, not faster, and the queries you have to write or not any easier. It is also a testament to their inferiority because HQL also provides a bypass route so you can enter JDBC queries directly. They provide this (I suspect) because for any complex query you simply can't construct it well in HQL.

Categories