What is a Model?
A model can be considered as a container that facilitates presentation view, behavior and/or persisting data to/from data source (i.e., database, etc.). Besides the data container elements, a model may or may not contain behavior (i.e. logic), depending on design context of corresponding architecture.
While the term “Model” is frequently discussed and used in Model-View-Controller pattern context, it is one of the most important considerations in the current world of software architecture.
Download the EISK 6.0 MVC Edition release to see few of the patterns mentioned in this post – in action!
Common Container Models
Entity
Entities can be considered as the “heart” of a data driven application and plays a primary role on all Model related patterns. By definition, each data container that is designed as an Entity - contains identity (i.e., primary key) and is typically utilized to store data in structured storage system.
Value Object Pattern
Value Objects are simple data containers which don’t have any identity. A value object may participate in an entity object as member to provide an object oriented style design or may itself be used as Data Transfer Object (discussed later) to transfer data.
Figure: The Person class represents an Entity, where as the Address class represents a Value Object
Model Set Pattern
As the name applies - a Model Set encapsulates a set of model objects in a single class.
While containing objects of different type in a single class is very common in software architecture and implementation world, defining the term “Model Set” in model related architecture context will enable understanding different boundaries in different scenarios.
Data Transfer Object Pattern
As the name applies, Data Transfer Object (DTO) is used to transfer data from one boundary to another. According to Fowler - an object that carries data between processes in order to reduce the number of method.
Data Transfer Objects can be considered a form of Model Set pattern, in addition with a mandatory responsibility of participation in transferring data.
Relevant patterns:
Business Models
Domain Model Pattern
By definition, Domain Model is - an object model of the domain that incorporates both behavior and data.
Models in a domain model object graph, contains core business logic. Domain object typically contains identity.
Trigger Model Pattern
Each model is responsible to execute relevant business rules, each of which is encapsulated in a separate class, containing utility methods to facilitate unit testing.
Figure: A sequence diagram demonstrating a portion of Trigger Model work flow. Click the image for larger view.
Relevant patterns:
- Single Responsibility Principle
- Transaction Script Design Pattern
- Domain Model Design Pattern
User Interface Models
Presentation Model Pattern
Presentation Model (also known as Application Model) represents the state and behavior of the presentation independently of the GUI controls used in the interface.
Apart from handling user interaction related behaviors, Presentation Model may utilize Presentation Data Models (discussed later) effectively to minimize user interface rendering logic in view.
Figure (courtesy:
Martin Fowler): How objects react to clicking the classical check box.
Presentation Data Model
It is often beneficial to create a presentation data model that contains decorated version of domain data models, which are completely presentation friendly.
For instance, if we have a property “Notes”, for a given employee in a domain object, we can create our view friendly model that will encapsulate necessary display logic in a property of presentation data model. In that way, we can reduce untestable and unmaintainable code from view. Such an example is shown as below:
Based on characteristics, Presentation Data Models can be categorized in 2 primary ways:
View Model Pattern
As mentioned earlier, instead of embedding display rendering logic to view, it is often beneficial for testing and maintainability to construct the view rendering logic in to a separate class before sending the model to view. View models are not typically designed to be persisted to database.
Some people consider “View Model” to have Editor related data as well, which I think is very confusing, as the term “View” provides a “read-only” impression. Patterns specific to editor related data are discussed later.
Relevant patterns:
- Façade Pattern
- Data Transfer Object
- Presentation Model
Editor Model Pattern
Editor model is a special model to facilitate rendering appropriate data in editor user interface, where the entity and other editor related objects are encapsulated in a single view friendly class and enables the entity to be persisted to database upon submission of data to service.
Relevant patterns:
- Façade Pattern
- Data Transfer Object
- Presentation Model
Editor Model Pattern can be categorized in 2 following ways:
Member Editor Model Pattern
Member Editor Model is a simple form of Editor Model pattern, where the persistence entity object is placed in a Model Set as a class member. Other class members of the Model Set include related presentation friendly objects.
Since the Model Set contains the database persistence entity, it requires very less coding effort to perform crud operation.
Relevant patterns:
- Model Set Pattern
- Façade Pattern
Adapter Editor Model Pattern
Adapter Editor Model Pattern combines the benefit of View Model and Editor Model pattern, with an additional overhead of adapter component that converts a editor model object to entity object to facility working with data access layer.
Relevant patterns:
- View Model Pattern
- Façade Pattern
- Adapter Design Pattern
Hope you found it useful. Cheers!
Add me on Facebook, if you like the post and are interested in learning my latest thoughts!
