Spring EYE on JAVA EE – Cond. View and Backing Bean/Domain Object Conversion

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.

Spring MVC is a sophisticated framework that makes UI works truly flexible and powerful. Here I am not going to cover all the aspects of MVC, but focus on the View, and try to address a common problem of the incompatibility of the view object and business object, and the solution.

In theory, all server side POJO business objects, the domain objects, could be used on the UI side without modification. But in reality, since domain object has complicated relationship linking to other objects, it is unlikely they can be used directly. For example, an Order object in the previous sample composed of OrderItems, which further associated with Products. On the server side, when associated with hibernate session, all the relationship can be retrieved when necessary (lazy loading), thus solved the dilemma between retrieve necessary data (needs load full object which is memory costing and low performance) and performance (lazy loading retrieve data only when necessary). But when the same object resides on the web side, only a fully loaded object can work since it is detached from hibernate session, but it will likely suffer the performance problem. Therefore, creating UI side backing bean object is a better approach than using the original business object.

In addition, unlike business objects, that defines relationship in associate, composite, and/or aggregation, with one or more other objects, UI backing beans are for display purpose, therefore, can be strip down to isolated objects.

In the next section, by developing the page to list all the existing orders, a standard way of creating backing bean, converting domain object to backing bean, and backing bean's usage is demonstrated.

The web page of order list is like the following:

First take a look on the Backing Bean: FlatOrderBean.java. From the class definition shows this class is extended from AbstractEntity.java, which is the base of all Entities. Backing Beans are no exception. One final member field of Class type defines what is the underline business class for this to associate with. It also implements I_FlatBean interface, which defines two methods. getBaseEntityClass() returns the underline business object class for this Backing Bean class, while setValue() populate the Backing Bean object by providing a corresponding domain object. This I_FlatBean defines all the necessary behavior for the DAO to CR this bean.

Then let’s revisit the uniform DAO class: HibernateEntityDAO.java. It now has the ability to identify if the request entity is in fact Backing Bean, and populate it and return it. The previous consolidation of DAO makes great sense here. This newly introduced Backing Bean can be retrieved without additional DAOes except a little modification on HibernateEntityDAO.

Write a unit test to make sure all steps works well. Notice in the unit test transaction needs to be handled programmatically.

Adding further methods in the façade interface so the above server side business can be transferred to web site. Finish it up with necessary jsp files and configuration changes.

Now the controller will looks as simple as the following:

In summary, this refactoring provides a simple, clean yet powerful way to convert pure domain objects to UI backing bean objects.

Previous: Uniform DAO    Next: JSF & Ajax