Java Vibes..

June 30, 2009

Template Pattern and Spring

Filed under: architecture & design — harjitdelhi @ 1:09 pm
Tags: , , , , ,

As you might be aware, Template is a GoF behavioral pattern. Here I first explain what the Template pattern is and then show an example of the pattern as implemented in the Spring framework:

Template works on the philosophy of Abstract classes, wherein the Abstract class implements some boiler plate functionality and let the subclasses implement the specifics.

For example, when you want to execute a JDBC query against a database, you have to implement the following steps:

  1. Obtain a DataSource
  2. Use the DataSource to get a Connection object
  3. Use the Connection object to create a Statement (or a PreparedStatement)
  4. Execute a query to get the ResultSet
  5. Iterate over the results and create a list of VOs (as an example of a business logic)
  6. Close the ResultSet
  7. Close the Statement
  8. Close the Connection

Out of the above steps, most of these are boiler plate code while steps #4 and #5 reflects the actual business logic. If you create a Template class (essentially an Abstract class) that models these steps and allow subclasses to customize the steps #4 and #5 then it will help subclasses reuse the boiler plate code.

Spring does this by providing classes like JdbcTemplate, HibernateTemplate, JmsTemplate etc.  Here is how things work in the Spring world:

template

Example code:
List results = getHibernateTemplate().executeFind(new HibernateCallback() {
                   public Object doInHibernate(Session session) {
                       Query query = session.createQuery("from Event");
                       query.setMaxResults(2);
                       return query.list();
                   }
});
Advertisements

June 22, 2009

Abstract Factory Pattern

Filed under: architecture & design — harjitdelhi @ 10:13 am
Tags: , , , ,

I had implemented an Abstract Factory in one of my projects. Posting the details of the implementation here.

The requirement is that for CDR database, there are 2 datasources, one for HongKong and one for US. And for ProdProfile database, there is only datasource for both locations. The location is not known at the compile time so we can’t inject datasource in the factory at compile time. Also passing the location in the getDao() method looks ugly since location is not required for all type of DAOs. And even ProductProfile datasource may become location specific in future.

I have tried to make one factory for each Location. The factory will instantiate different DAOs, whether the DAO is injected in the factory is location specific or not is controlled by Spring config.

AbstractDaoFactory:

CdrDao getCdrDao()
ProdProfileDao getProdProfileDao()
USDaoFactory extends AbstractDaoFactory
CdrDao getCdrDao()
ProdProfileDao getProdProfileDao()
HKDaoFactory extends AbstractDaoFactory
CdrDao getCdrDao()
ProdProfileDao getProdProfileDao()
CdrDao
setDS()
loadProductList()
CdrDaoImpl: 2 spring beans for this Impl, but different DS injected in these: USCdrDaoImpl, HKCdrDaoImpl
ChecklistDao
setDS()
loadChecklist()
ChecklistDaoImpl: just 1 spring bean for this Impl, so both factories will return the same instance
Class AbstractDaoFactory:
+ CdrDao getCdrDao()
+ ProdProfuleDao getProdProfileDao()
Class USDaoFactory extends AbstractDaoFactory
+ CdrDao getCdrDao()
+ ProdProfileDao getProdProfileDao()
Class HKDaoFactory extends AbstractDaoFactory
+ CdrDao getCdrDao()
+ ProdProfileDao getProdProfileDao()
Interface CdrDao
+ setDs(DataSource ds)
+ loadLegCodes()
Interface ProdProfileDao
+ setDs(DataSource ds)
+ loadAllSeries()
Class CdrDaoImpl: created 2 spring beans for this Impl, but different DS injected in these: USCdrDaoImpl, HKCdrDaoImpl
Class ProdProfileDaoImpl: created just 1 spring bean for this Impl, so both factories will return the same instance

Blog at WordPress.com.