Skip to main content

Spring - When to use jdbc versus O/R Mapping

What are the factors that determine when you choose different data access technologies? The access choices would then be straight JDBC, Spring's JDBC framework, iBatis, and Hibernate or JDO. The straight JDBC solution would, in our opinion, be the solution of choice only when you are not allowed to use any framework besides what is delivered in J2SE or J2EE.

If your project has only a few persistent classes or you have to map to an existing database with several stored procedures, then a Spring JDBC solution makes sense. There is very little to configure and if you have only a few classes to map to a Java class, then the MappingSQLQueyr makes mapping straightforward. The Storedprocedure class makes working with stored procedures easy.


If you have many classes that map to an existing database or you don't have control over the database design, then you have to look at the mapping options between the tables and your java classes.


When to Choose O/R Mapping
O/R mapping can have many benefits, but it is important to remember that not every application fits the O/R mapping paradigm.

Central issues are heavy use of set access and aggregate functions, and batch updates of many rows. If an application is mainly concerned with either of those — for example, a reporting application — and does not allow for a significant amount of caching in an object mapper, set-based relational access via Spring JDBC or iBATIS SQL Maps is probably the best choice.

Because all O/R mapping frameworks have a learning curve and setup cost, applications with very simple data access requirements are also often best to stick with JDBC-based solutions. Of course, if a team is already proficient with a particular O/R mapping framework, this concern may be less important.

Indicators that O/R mapping is appropriate are:

A typical load/edit/store workflow for domain objects: for example, load a product record, edit it, and synchronize the updated state with the database.

Objects may be possibly queried for in large sets but are updated and deleted individually.

A significant number of objects lend themselves to being cached aggressively (a "read-mostly" scenario, common in web applications).

There is a sufficiently natural mapping between domain objects and database tables and fields. This is, of course, not always easy to judge up front. Database views and triggers can sometimes be used to bridge the gap between the OO model and relational schema.

There are no unusual requirements in terms of custom SQL optimizations. Good O/R mapping solutions can issue efficient SQL in many cases, as with Hibernate's "dialect" support, but some SQL optimizations can be done only via a wholly relational paradigm

Comments

Popular posts from this blog

Stretch a row if data overflows in jasper reports

It is very common that some columns of the report need to stretch to show all the content in that column. But  if you just specify the property " stretch with overflow' to that column(we called text field in jasper report world) , it will just stretch that column and won't change other columns, so the row could be ridiculous. Haven't find the solution from internet yet. So I just review the properties in iReport one by one and find two useful properties(the bold highlighted in example below) which resolve the problems.   example:
<band height="20" splitType="Stretch"> <textField isStretchWithOverflow="true" pattern="" isBlankWhenNull="true"> <reportElement stretchType="RelativeToTallestObject" mode="Opaque" x="192" y="0" width="183" height="20"/> <box leftPadding="2"> <pen lineWidth="0.25"/> …

JasperReports - Configuration Reference

Spring - Operations with jdbcTemplate

This class manages all the database communication and exception handling using a java.sql.Connection that is obtained from the provided DataSource. JdbcTemplate is a stateless and threadsafe class and you can safely instantiate a single instance to be used for each DAO.


Use of Callback Methods
JdbcTemplate is based on a template style of programming common to many other parts of Spring. Some method calls are handled entirely by the JdbcTemplate, while others require the calling class to provide callback methods that contain the implementation for parts of the JDBC workflow. This is another form of Inversion of Control. Your application code hands over the responsibility of managing the database access to the template class. The template class in turn calls back to your application code when it needs some detail processing filled in. These callback methods are allowed to throw a java.sql.SQLException, since the framework will be able to catch this exception and use its built-in excepti…