In todays world, layered architecture is a very common approach among enterprise applications. Each layer has a specific task of its own, and each one is only allowed to speak just one below. For example, data access layer deals with querying and persistence of data, service layer coordinates business operations and interacts with data access layer, presentation layer handles rendering of suitable user interface as well as processing user requests while talking with service layer. In this picture, data transfer throughout the layers is achieved using domain objects. For example, data is fetched from target datastore, then transformed into domain objects in data access layer, and delivered to the presentation layer for rendering purposes. In a similar way, domain objects bound to UI are filled with user input, then passed into backend layers for processing.
However, employing same domain classes in every layer can cause some data related problems in those applications. One might see that data might get inserted, updated or deleted unintentionally, especially when an ORM tool, like Hibernate is used for persisting data, UI frameworks like JSF or Vaadin, in which state management is handled on server side, while domain objects are directly bound to user interface components, used to collect user input and deliver it to the backend. Moreover, employing domain objects UI interaction might cause several fields and methods which are only needed by presentation layer get added into them. For example, adding a selected field and its corresponding getter/setter is a very common issue in order to identify which rows are selected in a UI table. That 'selected' property has nothing to the with the domain model at all.
In order to prevent such data integrity problems, and keep domain classes clean from UI specific attributes and methods, one needs to create and use a separate model targeted to the presentation layer. It may appear with different names, like 'data transfer object', 'data value object' or 'view model' in different projects, and whatever you call it for, its main duty is to prevent direct interaction and manipulation of domain objects via user interface components.
Although, we take it as a separate model, view model classes mostly overlap with domain model classes. Indeed, domain model classes can easily be transformed into view model classes with some additions of fields and methods. Actually, it becomes a burden for developers to just create and use a second set of model classes which are almost identical to domain model. We propose a solution to automatically derive those view model classes from domain model classes using proxy pattern, and define an API to handle various data related tasks which occur while transforming domain objects into view model objects, apply those user changes occurred in those view model objects during UI interaction back again to domain instances etc. With the help of such an automatic view model creation mechanism, task of creating view model classes manually becomes unnecessary. In addition, view model – domain model back and forth transformations and data related operations can be performed easily through a standard API. In this session, I am going to talk about how to employ dynamic proxy class generation to obtain view model out of domain model classes, and discuss view model API in detail.