Always use a ViewModel template in MVC?

Question

In MVC in the controller, you must get the model from the database and convert it to a ViewModel before sending it to the view. Usually something like Automapper is used.

My question is: if you need to show all the properties of the Model in the view, as they are, does the ViewModel create its value?

If the Model and ViewModel should be the same, does creating a ViewModel create some security or benefits in the application, or are we adding unnecessary complexity?

Answer 1

The point of using the presentation model is usually because your presentation requires more / less information than what your domain model provides.

Other benefits include decoupling your view from your domain, which can be fragile if your domain develops.

Its essence is that this is not a necessity; The purpose of the presentation model is to provide only the information that it needs to render if you feel that the presentation model in your application will be redundant, and then do not use it. However, I would at least think about using an interface to avoid communication.

Answer 2

In addition to what has already been mentioned (problem separation, isolation, etc.), a separate ViewModel stops the leak of abstraction that may appear along with the database model. This is true, especially if you use EF with navigation properties enabled.

Say you have cars and wheels. You show cars in sight.

Case 1 (there is no separate ViewModel for cars): In razor mode, it’s very easy to have something like the following:

public class CarModelFromDB { public string CarName{get;set;} //More properties public IEnumerable<Wheel> Wheel{get;set;} } @model IEnumerable<CarModelFromDB> @foreach(var car in Model) { //some View Code @foreach(var wheel in car.Wheels.Where(x=>x.IsRound=true)) { <span>wheel.Color</span> // some View Code } } 

Now your logic of getting wheels with cars has leaked into the view, and also allowed you to choose the situation N + 1 . I do not think that there are other ways of testing.

Case 2 (with ViewModel for cars):. In this case, you can limit the presentation by sending only those things that he needs. It might look like this:

  public class CarViewModel { public string CarName{get;set;} //More properties public IEnumerable<string> WheelColors{get;set;} } @model IEnumerable<CarViewModel> @foreach(var car in Model) { //some View Code @foreach(var wheelColor in WheelColor) { <span>wheelColor</span> // some View Code } } 

Now your viewing code is very limited in terms of what it can do and it will not send any rogue requests to the database. Your controller really controls what kind it gets. You can click the wheel logic there or ideally in some service method that is called from the action method. In addition, you can conduct proper action method testing and feel confident about your system. Hope this helps.

Update

Case 3 (dynamic ViewModel): If you are comfortable with dynamic types , you can avoid all castings and mapping. As long as your gaze gets the properties he needs, he will be happy. No matter where they came from. Thus, the code will be:

  public class CarViewModel { public string CarName{get;set;} //More properties public IEnumerable<string> WheelColors{get;set;} } // pass the List<CarViewModel> to the view @model dynamic @foreach(var car in Model) { //some View Code @foreach(var wheelColor in WheelColor) { <span>wheelColor</span> // some View Code } } 

A potential drawback / additional work is to make sure that you have tests for the presence of these properties on the model.

Again, as mentioned earlier, this should not be construed as a single size corresponding to all types of solutions. These are some options and are used only if they make sense.

Answer 3

While this issue is likely to be closed, as based primarily on opinions, this is a really good question. A ViewModel almost always worth the effort in an application with extreme complexity.

Most applications will benefit from extending all ViewModel from BaseViewModel.cs , so in _Layout.cshtml you can show things like CurrentTab (highlight the current page of the navigation bar) or PageTitle . In this case, the view model is always needed as a derivative of BaseViewModel .

Answer 4

It is impossible to say, because we do not know what your model is, and whether there are any security problems.

In the general case, the security problem is not in transmitting the presentation model, but in receiving messages that are automatically bound to the data model. If you have sensitive information, someone can create a message that will change what you did not intend.

See http://odetocode.com/blogs/scott/archive/2012/03/12/complete-guide-to-mass-assignment-in-asp-net-mvc.aspx

The bigger the problem, the REALLY? And are you sure that they will remain the same? Are you sure that you will not need to make changes that require the presentation model to have different requirements for the data model somewhere along the line?

It’s easier to do the work in front and follow a good design than to try to fix it later when you need it.

Answer 5

Do you correctly state that an additional level adds complexity, redundancy, additional development time and synchronization. But this flaw is easily learned in a large complex application, especially in a command environment where different teams are assigned to different layers.

For small projects with several developers (usually 1 in your case), it is quite normal to use the same model in the user interface. Being small, you can easily remove an extra layer when it grows.

The ViewModel must support separation of concern, which is the main selling point of MVC. This separation allows your presentation and domain to grow safely independently. You can protect the domain from any changes in the presentation, and you can protect the presentation from any changes in the domain.

You may not notice this before, but ultimately the domain and presentation are guaranteed to change, and your code should be ready when that happens. This is what you are planning today so you can have breakfast tomorrow.

In addition, there are many ways to automate mapping from a domain model to view a model, such as AutoMapper.