Tres Amigos of Persistance (DAO - DAOFactory - BO)

Nowadays, even with all the good accumulated knowledge we have in design patterns, software engineers still tend to program classes where business logic is mixed with persistence logic. Even some experienced developers omit this important aspect of software architecture maybe for lack of knowledge, or just for the rush to start programming quickly. I consider the last reason is the most common of all. 

Now why should we bother too much about this separation? well, the idea is not to develop a case for what is basic in software architecture: multi-tier(layer) programming, but to help with some useful patterns to accomplish this fundamental aspect of a well design application. I think almost everyone is aware of this principle but I know for experience that for many it is not so obvious how we can meet all the details of persistence logic independence. 

First let's start with the most known pattern: Data Access Object (DAO). Citing from one design patterns book I have [1]:

Problem: You want to encapsulate data access and manipulation in a separate layer
 Forces:

1. You want to implement data access mechanisms to access and manipulate data in a persistence storage.
2. You want to decouple the persistent storage implementation from the rest of your application.
3. You want to provide a uniform data access API for a persistent mechanism to various types of data sources, such as RDBMS, LDAP, OODB, XML repositories, flat files, and so on.
4. You want to organize data access logic and encapsulate proprietary features to facilitate maintainability and portability. 

 The DAO classes will contain all the logic to connect for example to a database and get the needed data from the corresponding tables. One important aspect of this DAO is that any implementation should always avoid to return any persistence proprietary object. For example if someone codes a DAO where the returned object is a ResultSet, the class wouldn't be meeting the point #4. The application would be coupled to the JDBC implementation. That is why in the next UML diagram the returned object from the DAO is a "TransferObject". 

We don't have to get into much details of TransferObject pattern but I can say with just having domain objects is enough to ensure decoupling with business and persistence layers.

Having implemented the DAO pattern in our app does not decouple in 100% the business layer from the persistence one. Imagine for example you have this DAO class and the client that consumes it:

package com.foo.dao.jdbc;

class FooDAOJDBCImpl {
 public void updateFoo(Foo foo) {  
  ...
 }
}

public class FooClient {
 void updateChangesInFoo(Foo foo) {
  com.foo.dao.jdbc.FooDAOJDBCImpl fooDAOJDBCImpl = new com.foo.dao.jdbc.FooDAOJDBCImpl();
  fooDAOJDBCImpl.update(foo);
 }
}

Notice that the client needs to instantiate directly the JDBC implementation. Even though it is hidden for the client how the DAO class internally updates the data in the data source, the client still knows that the implementation uses JDBC to persist data. If the JDBC implementation has to be replaced by another one, the client code will have to be updated to use the new DAO class. 

To make our design more flexible to such type of possible changes, and also to have our code prepared for unit testing (use of mock DAO classes), we can marry our DAO pattern with the AbstractFactory pattern to have a child named DAOFactory. The DAOFactory class uses reflection (one way to do it) to instantiate the DAO class.

 

public interface DAO {

}

public interface FooDAO extends DAO {
 public void update(Foo foo);
}

package com.foo.dao.jdbc;
public class FooJDBCImpl implements FooDAO {
 public void update(Foo foo) {
  ....
 }
}

public class FooClient {
 void updateChangesInFoo(Foo foo) {
  FooDAO dao = (FooDAO) DAOFactory.getDAO("foo") ;
  dao.update(foo);
 }
}

It is not until execution time that is known what DAO class will be used to execute the persistence method. The name of the classes can be stored in a properties file. If the implementation of the DAO class is changed, it will be totally transparent to the Client class.

/**
Properties in some file:
foo=com.foo.dao.jdbc.FooDAOJDBCImpl
foo2=com.foo.dao.jdbc.Foo2DAOJDBCImpl

**/

import java.io.FileInputStream;
import java.io.FileNotFoundException;
import java.io.IOException;
import java.util.Properties;

public class DAOFactory {
 
 private static Properties props = new Properties();
 private static boolean loadedProperties = false;
 private static String propertiesPath;
 
 public static void init(String propertiesPath) {
  propertiesPath = path;
 }

 public static DAOFactory getDAO(String name) {
  try {
   
   Class daoClass = Class.forName( getClass( name ) ); 
   return (DAO) daoClass.newInstance();   
  }
  catch (ClassNotFoundException e) { 
   e.printStackTrace();
   return null;
  }
  catch (Exception e) {
   e.printStackTrace();
   return null;   
  }

 }
 
 private static String getClass( String propertyName ) {
  String className = null;
  try {
 
   if ( !loadedProperties ) {
    
    FileInputStream file = new FileInputStream( propertiesPath );
    props.load( file );    
    loadedProperties = true;
   }

   className = props.getProperty( propertyName, "");
   if ( className.length() == 0)
    return null;
  }
  catch ( FileNotFoundException e) { 
   e.printStackTrace();
  }
  catch ( IOException e) {   
   e.printStackTrace();
  }
  catch (Exception e) {
   e.printStackTrace();
  }
  return className;
 }

}

The last design pattern to complete our gang is the Business Object (BO). I'm still learning how to use it correctly, I just realized writing this post that I have some fixes to do in a current implementation I have. But anyways, one of the main purposes of this pattern is to separate the persistence logic from the business logic. Normally in our applications we have a complex conceptual model containing structured, interrelated composite objects. Those complex composite relationships between classes require a lot of logic just to persist. So to avoid mixing these two logic's, an intermediate layer between business logic and data access is created; the BO's layer. 

Let's suppose we have a class Foo containing a list of Foo2 objects:

public class Foo {
 private List<oo2> foo2s;
 private String someAttribute; 

}
public class Foo2 {
 private String someAttribute;
} 

If we want to persist our Foo class, we create two BO classes. The FooBO is the main entry point to save all the composite objects contained inside Foo2 domain class.

 public class FooBO {
 
 public void saveFoo(Foo foo) {
  FooDAO fooDAO = (FooDAO) DAOFactory.getDAO("foo") ;
  fooDAO.saveBasicFooInfo(foo);
  Foo2BO foo2Bo = new Foo2BO();
  
  for (Foo2 foo2 : foo.getFoo2s()) {
    foo2Bo.saveFoo2(foo2);
  }  
 }
}

public class Foo2BO {
 public void saveFoo2(Foo foo) {
  FooDAO2 fooDAO2 = (FooDAO2) DAOFactory.getDAO("foo2") ;
  fooDAO2.saveFoo2(foo2);
 }
}

There can be different ways to implement any of the 3 patterns described in this post; nothing is written in stone in the programming field. The idea was to provide a quick look on these three main patterns. If anyone has anything interesting to add, comments are well welcome. [1] Deepak Alur, John Crupi, Dan Malks. "Core J2EE Patterns, Best Practices and Design Strategies", 2003. Pags: 462,463.