Interaction Data Model vs Transactional Data Model

In the days of Entity beans in 2.1 ways, the existence of beans required the need for a container or a run time environment to manage those beans. This made it impossible to transfer those beans across the wire or across contexts as it was not possible for the new environment to always understand those beans. This prompted the need for patterns like Value object and Data Transfer object. The idea was to map the beans into the same kind of structure and without the baggage of run time environment needs.VO/DTO essentially was about mapping the entity beans data structure into another similar beans structure.

Then the world changed and the entity beans got replaced with POJO's. It was first made popular by Hibernate and then adopted by Entity beans 3.0. This made VO/DTO sort of redundant as the entity
beans themselves started getting used as VO/DTO's. Being agnostic to the environment, it was easy to transfer them across wires also.

Are VO/DTO not at all useful in the current POJO way of working. I think they are not useful if we are strictly dealing with a CRUD type structure in applications. However, it so happens that the application front end starts differing from the way the data model is structured at first place. The normal way of working with entity beans based POJO is that the front end gets the beans from service/dao layer. The beans are mapped into a serialized structure and are passed to the client which can be a browser in the case of the web application. This serialized structure is in the form of a key-value pair. The keys are generated in such a way that they can be mapped to entity beans POJO in an easy way even if the data points are sitting in a hierarchical structure. For simplicity let's call the page data model as an interaction data model because this is what the end user interacts with. The data model on the database side can be termed as a transactional data model.

Interaction vs Transaction Model

There are however a couple of points which makes it more complex with time:

• The page data structure with time starts diverting from the data model data structure as more things start appearing on the horizon. This makes the direct mapping of the data model to the page data model difficult.  For example, the data model may have an employee as a table but the page might want to show the employee and it's senior and subordinates in the same page. It's also quite possible that the employee may not be having relationships with the seniors and subordinates mapped in the entity model.
• We may not want to make the password the part of data structure that goes to the client while showing the details of employee. However, for the entity data model, the password field needs to be retained to maintain the integrity of the data model. There are cases where the only partial transactional data model is required to handle the interaction data model, but this requires the extra bookkeeping of fields either in a hidden field or to populate the data back into a transactional data model.
• The hierarchical depth poses another problem in dealing with the transactional data model. The interaction data model especially is not efficient in dealing with deep hierarchies as they make the keys quite long at times. This is especially true when we are dealing with tabular structures.

To deal with such kind of problems, I think it's important to look back into the VO/DTO patterns. The interaction data model can be driven from the perspective of the end user and the transactional data model can be driven from the perspective of databases. This also separates the concern of dealing with two different needs. The service layer can act as the mapper between two data models. This helps in exposing the interaction data model as web services also using automatic generators like JAXB and jersey. In hibernate world, this can also handle the lazy initialization exception in a more predictable way.