Use View Model to separate Domain Models in ASP. NET MVC

The MVC Architecture Pattern is one of the longest mentioned patterns in the programming world in recent years. Model View Controller (Model-View-Controller, MVC) the pattern organizes your software into three distinct roles:

◆ Model encapsulates your application data, application processes, and business logic.
◆ View obtains data from the Model and formats the data for display.
◆ The Controller controls the program process, receives input, and passes them to the 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: SimpleDomainModel and RichDomainModel.

SimpleDomainModel is usually a one-to-one communication between business objects and database tables. Several Modes you have seen: Active Record, Table Data Gateway, and DataMapper, all these database-related design patterns can help you organize database-related logic into a Domain Model.

RichDomain 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 RichDomain Model. However, if you are writing a core library worth millions of Enterprise Intranet architectures, it is worthwhile to develop a RichDomain Model, which can provide you with a platform that accurately expresses business processes, and allows you to transmit data quickly.

MartinFowler briefly introduces two Domain Models in PoEAA. EricEvans'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 the data transmission object DTO ). 12 ASP. net mvc best practices:

7-DomainModel! = View Model

Domain Model represents the corresponding Domain, but the View Model is created for the View needs. These two types may be different (generally). In addition, Domain Model 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 ORM code, you can use AutoMapper. for more information, see ASP. NET MVCView ModelPatterns, so what are the differences between Domain Model and View Model?

View Model is often seen in ASP. NETMVC 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 ORM tools such as EntityFramework. 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 domainmodels. There are many similarities between the domain Model and the View Model. We often simply use the DomainModel 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. Use the domain model as a view model, that is, the domain model is a 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. This ing relationship needs to be processed.

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 Modelbinder 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 AutoMapper, an open-source project in the. NET community.

Article