Sunday, August 3, 2014

Interaction Data Model vs Transactional Data Model

In the days of Entity beans in 2.1 ways, the existence of beans required the need of a container or a run time environment to manage those beans. This made it impossible to transfer those beans across wire or across contexts as it was not possible for the new environment to always understand those beans. This prompted the need of 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 get the beans from service/dao layer. The beans is mapped into a serialized structure and is passed to client which can be a browser in the case of web application. This serialized structure is in the form of 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 interaction data model, because this is what the end user interacts with. The data model on the database side can be termed as transactional data  model.
Interaction vs Transaction Model
Interaction vs Transaction Model
There are however couple of points which however 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 data model to the page data model difficult.  For example the data model may have 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 client while showing the details of employee. However for entity data model, the password field need to be retained to maintain the integrity of data model. There are cases where only partial transactional data model is required to handle the interaction data model, but this requires the extra book keeping of fields either in hidden field or to populate the data back into a transactional data model.
  • The hierarchical depth poses another problem in dealing with transactional data model. The interaction data model especially are not efficient in dealing with deep hierarchies as they make the keys quite longer 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 end user and the transactional data model can be driven from the perspective of data bases. 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.

No comments:

Post a Comment