Java Persistence - Fun with Generic DAOs

Handling Java persistence through DAOs have really picked up, particularly among small to mid-sized application development space, who cannot afford to have a full fledged ORM implementation. In my last post on the subject of Java persistence, I projected ORM and DAO as cooperating technologies (rather the competing ones) and suggested that mid sized applications should use both to ensure proper layering and separation of concerns.

Firestorm/DAO from CodeFutures is one of the very popular products in the market today that generates all DAOs and POJOs once you feed in your schema for the database. The code generator from Firestorm/DAO generates one DAO interface and one implementation class for each database table along with separate classes for the DTOs, factories and the exceptions. Looking at the generated code, I somehow have the feeling that they could have been better engineered through employing a higher level of abstraction. For every DAO, the basic functionalities provided are the same; e.g. findByPrimaryKey() locates a record from the table using the passed in primary key; findAll() fetches all records from the table - yet we do not find any base class abstracting the commonality of SQL processing!

In the meantime, I have been doing some work outs on generic DAOs, with the idea of making the generated code more compact and better engineered without sacrificing an iota of typesafety. My last posting on this subject has some information on what I thought could be the base of my design - a Bridge based implementation of generic DAOs -

• the interface hierarchy providing the contracts to be extended by application DAOs


• the implementation hierarchy, providing options to implement the DAOs using different engines like JDBC, Hibernate etc.

Here's a sample usage for a table Employee for executing a query with a dynamic criterion :

// make the DAO
EmployeeDAO<Employee> e =
    DAOFactory.getInstance().getEmployeeDAO();

// make the criteria
ICriteria cri = new SimpleCriteria("employee_id = 10");

// get 'em
List<Employee> es = e.read(cri, Employee.class);


Note that in the above snippet, EmployeeDAO is a generic class and takes a POJO as the actual parameter of instantiation. EmployeeDAO has been generated as :

public class EmployeeDAO<T extends DTOBase> extends DAOBase<T> {
    ....
}


An alternative could have been to have the EmployeeDAO as a concrete class with the POJO Employee hardwired :

public class EmployeeDAO extends DAOBase<Employee> {
    ....
}


Well, it really depends upon how much flexibility you would want to give to your users. With the former approach, the user is allowed to construct the EmployeeDAO with any other POJO, so long the POJO contains the properties that match the database column names. This is often useful when the user wants to work with database views in the application, which has different backing POJOs than the ones associated with the main tables.

The abstraction DTOBase provides a suitable container for dumping all stuff common to all DTOs, e.g. bean state management functionalities (whether it has been changed since its last fetch from database) are very powerful candidates for this placeholder. Incidentally these functionalities are scattered throughout all POJOs in Firestorm/DAO generated codes.


Projection on a Table is also a DAO!

With the above code snippet for query, we can read entire records from the Employee table to the List<Employee>. Now what about projections - I want to select a few columns of the table into my POJO. The point to note is that the end result of a Projection is no different than the above read(), except the fact that we now have a smaller list of columns to deal with. It's no different from an operation on a DAO, which transforms the end result to contain a subset of the column list.

Think Decorator! Decorate a DAO to get the Projection :

public class Projection<T extends DTOBase> extends DAOBase<T> {
    private DAOBase<T> base;
    ...
}


And now the usage :

// set up the Projection
Projection<Employee> ep =
  DAOFactory.getInstance()
    .getEmployeeProjection()
    .setColumn(EmployeeDAO.ColumnNames.EMPLOYEE_ID)
    .setColumn(EmployeeDAO.ColumnNames.EMPLOYEE_NAME);

// get 'em
List<Employee> es = ep.read(cri, Employee.class);


Cool stuff ! We have the encapsulation of the SQL married to the typesafety of operations. The user does not have to write SQL statements or use hardcoded column names that can be checked only during runtime. That was the promise of the DAO Design Pattern - right ?


How about Joins ?

Joins are nothing but compositions of multiple tables based on primary key / foreign relationship. The result of a Join is also a DAO!

public class Join<T extends DTOBase> extends DAOBase<R> {
  public Join<T> addJoinParticipant(DAOBase<? extends DTOBase> dao){
  ...
  }
}


Compose as you Wish

// make the DAO
EmployeeDAO<Employee> e =
DAOFactory.getInstance().getEmployeeDAO();

// make the DAO
EmpSalaryDAO<EmpSalary> s =
DAOFactory.getInstance().getEmpSalaryDAO();

// make the criteria
ICriteria cri = new SimpleCriteria(
new StringBuilder(128)
    .append(EmployeeDAO.ColumnNames.EMPLOYEE_ID.name())
    .append(" = 10").toString());

Join<EmpSalaryDetails> d =
    DAOFactory.getInstance()
      .getEmpSalaryDetailsDAO()
        .addJoinParticipant(e)
        .addJoinParticipant(s)
        .addLeftColumn(EmployeeDAO.ColumnNames.EMPLOYEE_ID)
        .addRightColumn(EmpSalaryDAO.ColumnNames.EMPLOYEE_ID);

Projection<EmpSalaryDetails> esd =
    new Projection<EmpSalaryDetails>(
        new DAOJDBCImpl<EmpSalaryDetails>(),
        d);

// get 'em
List<EmpSalaryDetails> es = esd.read(cri, EmpSalaryDetails.class);