Spring EYE on JAVA EE – Cond. Uniform DAO Implementation

Spring Eye on JAVA EE: Spring’s Practical Example for Enterprise Application

Source Code with no library jars. Build works in Eclipse env. Require separate Tomcat Installation.

From the previous electronic store example, a skeleton of a distributed web application has been constructed. It has a web tier, which talks with the façade app tier via RMI. The app tier communicates with individual entity DAO to acquire the necessary data, while DAO persist the entity into underline database.

Since all DAOes provide similar CRUD functionalities and it is a common refactoring approach to consolidate similar behavior, thus, it makes sense to implement a uniform DAO.

Close look at the entity reveals there are two major types of entity objects. One represents the data that is changed frequently, means CRUD operation is common for them. The other represents rather stable data, only likely operation toward them is READ.

In addition, the quantity of the entity objects needs to be put into consideration as well. Large quantity usually leads to persistence into database. But for the rather stable data with rather limited amount, it makes sense to cache them so the availability is fast and reliable.

Applying the above consideration, among five entities involved in the demo application, Order, OrderItem, and ReportInstance, are obviously fit for the database persistent, frequent CRUD type. Report, on the other hand, fits for the in memory candidate for its stability. Remember in Use Case, we only define two reports. The rather unique entity, Product, which only has stable eight instances defined in the Use Case, can be categorized into either type. In this demo application, it is implemented as the first type, only been striped out CUD functionalities. Its creation is handled by scripting in by SQL Statement.

AbstractEntity.java is created as the base class for all entity to be extended from.

An interface, I_IDBaseLookup.java is created, has only two methods, getEntity(int id) which acquire the entity by its ID, and getEntities() which returns all entities. In this way, the 2nd type entity can be separated from the 1st type, by identifying them by I_IDBaseLoopup.

HibernateEntityDAO.java is created to satisfy the uniform DAO access. In the implementation, entity class is passed in as argument while the code derived mapping based on this, then further complete CRUD functions. All I_IDBaseLoopup object was singled out so its unique implementation can take place.

Additional changes needed for the concrete entities like Order, OrderItem, etc. Here I only implement Order for the demonstration purpose so the old example of Product still works.

The original HibernateOrderDAOTest.java is modified to demonstrate how to use the above HibernateEntityDAO.java. It is clear that the only change was the replacement of the HibernateOrderDAO with HibernateEntityDAO. Obviously configuration file need to be updated to reflect this dependency change as well.

Report.java implements I_IDBaseLoopup by stores static defined Report objects in a Map. This implementation detail for sure is not the only one. Interested Audience may create his/her own.

In summary, this uniform DAO release the developer from creating its own DAO for each individual entity object. In addition, the implementation of Report.java represents a simple way for creating static in memory entities.

Previous：Enterprise Practice    Next: View & Flat Bean