Use the view model to separate the domain model from the presentation layer

The Model-View-controller (Model-View-controller, MVC) mode organizes your software into three distinct roles:

• The model encapsulates your application data, application processes, and business logic.

• View obtains data from the model and formats the data for display.

• Controller ControlProgramProcess, 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. On the contrary, MVC is more like a conceptual guiding principle or paradigm. The conceptual MVC pattern is described as the relationship between the three objects-model, view, and controller. Since both view and controller can request data from model, both controller and view depend on model. Any input enters your system through the Controller, and then the Controller selects a view to send the result.

Model contains your application logic and data. In your application, it is likely to be the main value drive. The model does not have any features related to the presentation layer and is completely irrelevant to the HTTP request processing responsibilities.

Domain model is an object layer that abstracts the real-world logic, data, and problems your application processes. Domain model can be divided into two categories: simple domain model and rich domain model.

Simple domain model is usually a one-to-one communication between business objects and database tables. Several Modes you have seen: Active record, table data gateway, and data mapper, all these database-related design patterns can help you organize database-related logic into a domain model.

The rich domain model contains complex object networks that are closely linked with inheritance mechanisms. The many patterns introduced in this book and in gof play a leveraged role. Rich domain models is often flexible, well-tested, constantly restructured, and closely coupled with the business logic required for the fields they express.

The domain model type depends on your application environment. If you are creating a very simple form processing web application, you do not need to create a rich domain model. However, if you are writing a core library worth millions of Enterprise Intranet architectures, it is worthwhile to develop a rich domain model, it provides you with a platform that accurately expresses business processes and allows you to transmit data quickly.

Martin Fowler briefly introduces two Domain Models in poeaa. Eric Evans's domain Driven Design book focuses entirely on the practical application and development process of rich domain model.

View is used to handle all performance Layer issues. View obtains data from the model and formats it into HTML for Web pages, XML for Web Services, or text for email.

The implementation of many MVC models also uses the concept of a view model or application model. controller is the medium of communication and serves as a bridge between the domain model and the user interface. It belongs to the presentation layer. For the simplicity of the view, the Controller is responsible for processing or converting the domain model into a view model, which is usually called a data transmission object (DTO ).

<Translation> there are 12 best practices for Asp.net MVC for model:

7-domainmodel! = Viewmodel

 Domainmodel represents the corresponding domain, but viewmodel is created for the view needs. The two may be different (generally). In addition, the domainmodel is a combination of data and behavior, which is composed of complex variable types and has layers. Viewmodel only consists of some simple variable types such as string. If you want to remove the redundant and error-prone OrmCode, You can useAutomapper. If you want to learn more, I recommend reading:ASP. net mvc view model patterns.

So what is the difference between the domain model and the view model?

View model is often seen in ASP. net mvc applications. We often think that the domain model and view model are the same thing. This is especially when the domain model is included in the DTO data transmission object, for example, the entity generated by using an ORM tool such as Entity Framework. In this case, the domain model is very similar to the object contained in the view model, and they are all simple crud operations.

These entities have many attributes and have the same or similar names. You can easily map an attribute in the view model of a domain object. However, these similar attributes may also be slightly different, such as the type or format. For example, an attribute of the user interface filled in by the user may be an "nullable" in the view model. On the other hand, domain entities may need a verified legal value, so a conversion between domain models on the user interface is required. In another example, the user interface may display a slider used to select how many days to submit his order. In this case, the view model may be represented by an integer attribute. The domain model is usually a date value.

A view model usually contains only a subset of a domain model and only the attributes required on the interface. In addition, the view model may be a flat version of a domain model tree. For example, a customer entity has an address, which is a whole. It contains the street address, zip code, and country. A customer view model is used to show data and flat the address data to the view model class.

In addition, if a view needs to process several domain models at the same time, the view model is the sum of these Domain Models. There are many similarities between the domain model and the view model. We often simply use the domain model as the view model.

We have discussed the similarity between the domain model and the view model. We can see that there are several ways to convert the domain model to the view model. There are usually three methods:

1. The domain model is used as the view model, that is, the domain model is the view model, most of which are used in this way.
2. The view model contains a domain model and defines a view model. It contains a domain model that can be accessed through attributes.
3. Map the domain model to the view model. The domain model is not directly mapped to the view model. You need to deal with this ing relationship.

We do not recommend that you directly expose the domain model entity to the view, because there are many nuances that may lead to the logic of your hybrid business and presentation layer, whether it is the attribute display of domain entities or the validation rules of businesses, this is different aspects of application processing. Directly using your domain model as the processing parameter on the conroroller faces security risks, because the Controller or model binder must ensure that the property verification and the user cannot modify attributes that cannot be modified by themselves (for example, the user manually updates a hidden input value or adds an additional attribute value. This is not an element on the interface, but it is the attribute of the domain model entity, this risk is called "over-posting"). Even if the domain model of the current version is correctly verified, the domain model may be modified in the future without any compilation errors or warnings, it may lead to new risks.

We should avoid converting the domain model into a view model using the first two methods. We recommend that you use the third method to define a separate view model class. It is a repetitive task to convert a domain model to a view model. Several tools are available to help you complete this task. One of the most common tools is. net.CommunityOpen-source project automapper.

 

For how to use automapper, refer to the following two articles.ArticleIntroduction:

Automapper formatters are cool-ASP. net mvc Style

Automapper in nerddinner