Separating the domain model from the presentation layer using view model

The Model-view-controller (model-View-controller, MVC) pattern organizes and decomposes your software into three distinct roles:

Model encapsulates your application data, application processes, and business logic.

View gets the data from Model and formats the data for display.

Controller control program flow, receive input, and pass them to Model and View.

Unlike other design patterns, the MVC pattern does not directly reflect a class structure that you can write or configure. MVC, on the other hand, is more like a conceptual guideline or paradigm. The conceptual MVC pattern is described as a relationship between three objects--model, View, and controller--. Since both view and Controller can request data from model, Controller and view are dependent on model. Any input is entered into your system via Controller, and then Controller Select a View to emit the result.

Model contains your application logic and data, which in your application is likely to be the primary value drive. Model has no performance-related features and is completely unrelated to HTTP request processing responsibilities.

Domain Model is an object layer that is an abstraction of real-world logic, data, and problems that your application handles. Domain model can be divided into two main categories: simple domain model and Rich domain model.

Simple Domain Model is often a one-to-one communication between business objects and database tables. Several patterns you've seen--active record, Table data Gateway, and data Mapper, all of these database-related design patterns-can help you organize database-related logic into a Domain model.

Rich Domain model contains complex, interconnected network of objects using inheritance mechanisms, and many of the patterns described in this book and GoF play a leveraged role. Rich Domain Models are often flexible, carefully tested, constantly refactored, and tightly coupled with the business logic required for the areas they represent.

Which type of Domain Model to use depends on your application environment. If you are building a very simple form-processing Web application, it is not necessary to build Rich Domain model. However, if you are writing a core library of millions of enterprise intranet architectures, it is worthwhile to strive to develop a Rich Domain Model that will provide you with a platform to accurately express your business processes and allow you to quickly transfer data.

Martin Fowler A brief introduction of two Domain Model in POEAA. Eric Evans's domain driven design is fully focused on the Rich Domain Model's practical application and development process.

View is used to address all aspects of the presentation layer. View takes data from Model and can format it as HTML for Web pages, XML for Web services, or text for email.

The implementation of many MVC patterns also uses a view model or application model concept, Controller is the communication medium, the bridge between the domain model and the user interface, belong to the performance layer. For the simplicity of view, controller is responsible for processing or converting the domain model into a view model, which is often called a data transfer object (DTO).

< translation >12 a asp.net mvc best practices for model best practices:

7–domainmodel!= ViewModel

Domainmodel represents the corresponding domain, but ViewModel is created for view needs. The two may (in general) be different, and Domainmodel is a combination of data plus behavior that is composed of complex variable types and has layers. ViewModel only consists of a few simple variable types, such as String. You can use AutoMapper if you want to remove redundant and easily error-prone ORM code. If you want to learn more, I recommend reading: asp.net MVC View Model Patterns.