Let me give you my view, the approach I do believe in...
Data Layer - The mapping Entity
vs Table
is a Data layer related. It is just a way, how to later profit from ORM tool like NHibernate. All the CRUD operations are generated for us - reflecting the mapping.
Presentation Layer - The ViewModel
, should help us to "map" the Entity(-ies)
to Client View
. So while in many simple scenarios will: Entity, Table, ViewModel .. (e.g. Country
or Currency
) match 1-1, we are ready to handle it differently in more complex scenarios.
The above scenario Displaying Person, Address, Jobs at one View - is a complex one. Can we profit from separation, indirect filling of the ViewModel
?
Suggestion: Fill the ViewModel
on a Service layer using queries to underlying Business model
The first benefit I see, is that the population of the ViewModelPerson
is in our hands. It is not fixed inside of the mapping. We can reduce amount of data (even use Projections to load less data) and we can even extend it (load City from some CodeList)
The second benefit is that if we will need to change something, e.g. introduce async loading of the Addresses
, we have to change it only from the Service layer UP (in MVC Controller, Model and View) while the data layer (mapping is untouched)