What is 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 most important consideration in 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 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:

• Model Set Pattern

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 on 2 primary ways:

View Model Pattern

As mentioned earlier, instead 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!

Subscribe me on Facebook, if you like the post and are interested to learn my latest thoughts!