Scope in asp.net MVC 3

Question

I read online that using a "model for the kitchen" is a bad practice:

Rule number 3 - View dictates the viewModel design. Just what is required to render a view using the ViewModel.

If the Customer object has fifty properties, but only one component shows its name, then we create our own ViewModel type with only these two properties.

However, Jimmy Bogard subsequently explained how good it is, but I asked a little. It would be so simple that my model simply contains a list of clients, I could even use my POCO.

So, now I can create custom small fragments of the view model for each page of the site? Each page using the Customer property will receive one, but, of course, cannot be used, because some information is extraneous if, for example, one page used Age, but not Name. Two new classes of mini-models?

This is a very time-consuming task, and it looks like it will lead to the creation of a million small models of user views - can someone clarify how useful this approach is and why is the simpler approach bad?

Answer 1

Viewing the model class can be used not only to convey values, but also defines data types (data annotations), validation rules, and relationships other than those used in the model. Some of the benefits that come to my mind right now:

• When changing a user's password, there are various rules for checking whether to change its basic data or its subscription settings. It can be difficult to define all of these rules in a single model class. It looks much better and cleaner when using different viewing models.
• Using a view model can also give you performance benefits. if you want to display a list of users, you can define a view model with an identifier and a name and use the index to retrieve from the database. If you received whole objects and passed them for viewing, you are transferring more data from the database than you need.
• You can define the display and editor templates for view models and reuse them on different pages using html helpers. This looks a lot worse when you define patterns for POCOs models.

Answer 2

If you use your POCO objects as presentation models, you essentially have to show your private objects and break the encapsulation. This, in turn, would make your model difficult to change without changing the corresponding views.

Your data objects may contain information that is appropriate only for the data access layer. If you bring these things into view, someone may change those values ​​that you did not expect to change and cause errors.

These considerations include many of the same reasons as for private members in OO languages. This, as they say, is still very often violated, because it is a big part of the extra work to create all these “discarded” models that are used only once. There is a framework for creating such models, although the name eludes me, which can bind objects together and highlight interesting properties only in order to remove some of the hard work from creating certain viewing models.

Answer 3

Your view model displays an idea of ​​how the data should be displayed. He expresses a model. I do not consider it necessary to have two viewing models unless you have two ways to express your model. Just because you have two pages, this does not mean that you will show the data in a different way, so I will not waste time creating two mini-models of viewing, when it can be in one model of multiple viewing. Imagine if later you have a page that needs a name and age, would you create a different presentation model? This is absolutely stupid. However, if you had two pages showing "age" and needed to be shown in a different way, I would create another.