Spring ORM DAO Module
The initial introduction of this module is also same as JDBC DAO Module regarding DAO introduction, DataSources configuration, and Exception classes.
But the module mainly contains Spring vendor provided classes that are developed on top of various ORM frameworks such as Hibernate, TopLink, iBatis, JDO, OJB, JPA, KODO, Apache Cayenne, Apache Torque, Athena, Carbonado, Dozer, Ebean, EclipseLink, Enterprise Objects Framework, JOOQ (Java Object Oriented Querying), JPOX (Java Persistent Objects), Object Relational Bridge (OJB), Open JPA, Orman, ORM Lite, QuickDB ORM, Sobat, JPMapper, Floggy, JOPS.
JDBC increases the complexity of DB programming in Java because for instance when we take a bean from client we need to map bean properties to table columns in the SQL command, perform insert or update or delete operation. Whenever we execute query we need to extract the content of the resultset using next(), getInt(), getString() methods etc and store them into DB. Dealing with so many single, double quotations and concatenation operators while create SQL command. And almost it crossed more than a decade and half using JDBC API we want more sophisticated features that what JDBC is providing:
Lazy loading – As our object becomes more complex such as Employee has one-to-many relationships Attendance, Payroll, On-to-One relationship with bank account, many-to-one relationship Department. Whenever we fetch Employee we don’t want to fetch all relational objects from DB.
Eager fetching – Eager fetching is opposite to lazy fetching, whenever we retrieve Employ object we want to fetch all relational objects from DB in a single query command.
Caching – For data that is read-only, read-mostly, we don’t to fetch this from the DB every time it is used. Caching can add significant performance boost.
Cascading – Sometimes changes to one DB table should result in changes to the other tables as well. As we discussed in previous example if we delete one record from Employee table, we want to delete records from all related tables of Employee table except record from Department. Because Employee to Department is weak association, Employee to other tables is strong association.
ORM is the best answer for the above mentioned features.
In Hibernate also we are having the same HibernateTemplate and HibernateDaoSupport classes as same as JDBC DAO module.
HibernateTemplate must be created and injected into our HibDAO component in following way:
<!-- DataSource configuration -->
<bean id="ds" class="org.apache.commons.dbcp.BasicDataSource">
<property name="driverClassName" value="oracle.jdbc.driver.OracleDriver"/>
<property name="url" value="jdbc:oracle:thin:@localhost:1521:XE"/>
<property name="username" value="username"/>
<property name="password" value="password"/>
</bean>
<!-- SessionFactory configuration -->
<bean id="lsfb" class="org.springframework.orm.hibernate3.LocalSessionFactoryBean">
<property name="dataSource" ref="ds"/>
<property name="hibernateProperties">
<props>
<prop key="dialect">org.hibernate.dialect.OracleDialect</prop>
<prop key="show_sql">true</prop>
<prop key="hbm2ddl.auto">update</prop>
</props>
</property>
<property name="mappingResources">
<list>
<value>Emp.hbm.xml</value>
</list>
</property>
</bean>
<!-- HibernateTemplate wraps Hibernate Session, Transaction and Query objects into a single object. Intention is instead of using so many classes single class is sufficient to perform all operations on hibernate. When we are using Hibernate API we need to handle HibernateException but that HibernateException is converted into DataAccessException in this module. Hence no need to handle exception in our DAO. -->
<bean id="ht" class="org.springframework.orm.hibernate3.HibernateTemplate">
<constructor-arg ref="lsfb"/>
</bean>
<bean id="ehdao" class="beans.EmpHibDAO">
<property name="hibernateTemplate" ref="ht"/>
</bean>
Example on HibernateDaoSupport, HibernateTemplate, HibernateTransactionManager, LocalSessionFactoryBeans are covered in Jdbc DAO Module.
