Click here to Skip to main content
12,943,742 members (59,027 online)
Click here to Skip to main content
Add your own
alternative version

Tagged as


9 bookmarked
Posted 18 Jan 2013

Design Patterns for Model

, 18 Jan 2013 CPOL
Rate this:
Please Sign up or sign in to vote.
Design patterns for Model

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


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:

  • 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 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!


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Mohammad Ashraful Alam
Chief Technology Officer
Bangladesh Bangladesh
Mohammad Ashraful Alam is a Software Engineer, who is dedicated to Microsoft .NET based development. This Bangladeshi national is involved with project management and development of several US based software projects from his country. Already he has managed and developed 15 software projects, which are being used by several users of different countries, such as USA, Canada, Australia, and Bangladesh. While developing and managing a team, he contains and maintains a set of well defined engineering practices developed by him and other online developer community. Beside software development, he has also written several technical articles and research papers published by IEEE Computer Society and many other worlds recognized publishers.

Before becoming engaged with software development, he was involved with Bengali literature and several Bengali news papers as freelance journalist and published around 150 articles, essays and short stories.

Due to his willingness to give effort to improve and share better software development practices, Ashraf has awarded as “Most Valuable Professional” (MVP) in ASP.NET category by Microsoft for multiple times, since 2007.

When not engaged with technical stuffs, he likes to pass time with his friends, and family members, listens music or watches TV.

Check his portfolio at:

Check his blog:

Catch him thru mail: admin [attt] ashraful [dotttt] net (anti-spam text).

You may also be interested in...


Comments and Discussions

-- There are no messages in this forum --
Permalink | Advertise | Privacy | Terms of Use | Mobile
Web02 | 2.8.170518.1 | Last Updated 18 Jan 2013
Article Copyright 2013 by Mohammad Ashraful Alam
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid