MVC: Data Models and View Models

為{幸葍}努か 提交于 2019-11-27 11:32:56

At its heart, two models is about Separation of Concerns. I want my View to work off of a single Model. I want my Domain Model to represent the conceptual model I build with the domain experts. ViewModel often has technical constraints. Domain Model is about POCO, and not being bound by technical constraints of either data shown (View) or persisted (in a DB or otherwise).

Suppose I have three entities shown on a screen. Does that mean I need to force a relationship between the three? Or just create a ViewModel component object that contains all three items. With a separate ViewModel, View concerns are separated from my domain.

why? 'cause the view shouldn't have the ability to use the model object!

Imagine you pass the project to a web designer to do the view layer. Suddenly he/she has the ability to mess around with your application's data through the model layer. That's not good.

So always only pass the data the view needs, instead of the object with methods.

J.P. Boodhoo's article Screen Bound DTOs will help you understand the design benefit.

There is also a security benefit that I have written about.

Having a presentation model simplifies your views. This is especially important because views are typically very hard to test. By having a presentation model you move a lot of work out of the view and into the domain->presentation model. Things like formatting, handling null values and flattening object graphs.

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

There are even plainer concerns including the view model's ability to be specially formatted and certainly null-safe.

I guess the idea is that your domain models might extend to other implementations, not just your MVC application and that would break the seperations of concerns principle. If your View Model IS your domain model then your domain model has two reasons to change: a domain change requirement AND a view requirement change.

Seems I have duplication of rules as well.

ie. client object validation on the UI, then mapping to domain object that has to be validated.

What I tend to do however is map my set of domain objects to create a model - ie. a webpage that shows customer info, stock info, etc... my model becomes a structure that holds a Customer object and a Stock object.

CompanyPageModel

public Customer Customer{get;} public Stock Stock {get;}

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

Separation 'seems' like more work, but later, it's good to have this division of UI/Domain model...sorta like writing tests :)

MvcCmsJon

I have drunk the cool-aide finally, I do like being able to mark my viewmodel with display instructions and have that all auto wired up.

What I demand now is some kind of auto generator of viewmodels from poco entities. I always set some string as an int and it takes me forever to find it. Don't even think of doing this without automapper unless you like pain.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!