MVC: data models and view models

Question

In the past, I read a few MVC tips on models that state that you should not reuse the same model objects for the domain and view; but I could not find anyone who would like to discuss why this is bad.

In my opinion, creating two separate models - one for the domain, one for the presentation - and then matching between them creates a lot of duplication, as well as a tedious matching code (some of which can be mitigated by things like AutoMapper ), which probably will be error prone.

What makes having a separate model for the two problems facing the problem of duplication and display of code?

Answer 1

At the heart of everything, two models are the separation of problems. I want my view to work on the same model. I want my domain model to represent the conceptual model that I create with the help of domain experts. ViewModel often has technical limitations. The domain model belongs to POCO and is not related to the technical limitations of the data shown (View), or stored (in the database or otherwise).

Suppose there are three objects on the screen. Does this mean that I need to force the relationship between the three? Or simply create a ViewModel component object containing all three elements. Using a separate ViewModel, View problems are separated from my domain.

Answer 2

why? because the view should not be able to use the model object!

Imagine you are submitting a project to a web designer to create a view layer. Suddenly, he / she has the opportunity to mess with his application data through the model layer. This is not good.

Therefore, you should always pass only the data that the view needs, and not an object with methods.

Answer 3

JP Boodhoo Article Related Screen DTO helps you understand the benefits of design.

There is also a security guide that I wrote about.

Having a presentation model simplifies your presentation. This is especially important because submissions are usually very difficult to verify. Having a presentation model, you move a lot of work from the presentation to the domain-> presentation model. Things like formatting, handling zero values, and aligning object graphs.

I agree that additional juxtaposition is a pain, but I think you probably need to try both approaches in your specific context to see what works best for you.

Answer 4

There are even clearer problems, including the ability of the presentation model to be specially formatted and, of course, zero.

Answer 5

I suppose the idea is that your domain models can extend to other implementations, not just your MVC application, and that violates the principle of separation of principles. If your view model is a model of your domain, then your domain model has two reasons for the change: the requirement to change the domain and change the view requirement.

Answer 6

I seem to have duplicate rules too.

i.e. checking the client object in the user interface, and then matching the domain object to be verified.

However, I try to make my set of domain objects create a model, i.e. a web page that shows customer information, stock information, etc ... my model becomes a structure that contains a Customer object and a Stock object.

CompanyPageModel

Public client client {get;} public stock {get;}

then in my mvc project ViewData.Model.Customer.Name ViewData.Model.Stock.CurrentStocks

The separation "seems" more like working, but then it's good to have this separation of the UI / Domain model ... sorta like writing tests :)

Answer 7

I finally drank a cool helper, I like being able to tag my model with display instructions and do it all automatically.

What I demand now is a kind of auto-generator of view modes from poco objects. I always set some string as int, and I need to find it forever. Don't even think about it without an automapper if you don't like the pain.