Using a model of a model + data view in ASP.NET MVC to support typed views?

Question

How do most developers handle typed views in ASP.NET MVC when working with large applications? We are considering the possibility of installing view-oriented models in the Models folder, and then placing all domain objects in a separate project. Thus, our controllers can easily add a domain object to a typed view if the domain object does not need to know the layout of the view itself.

For example, if we have an Employee object with:

• Id
• Name
• Surname
• Status

Then our Employee View can use the ViewEmployeeModel object with:

• Employee object
• List for Status dropdown
• etc.

Is this a smart approach? Are there any better ways to do the same? It seems a little strange, since I basically have two models (one for the view, one for the business objects), but isn't it better than using untyped views?

Answer 1

I do this almost as a rule because:

• It allows you to first create an application, not DB-first, which is nice when working with customer representatives.
• Typically, views have a much flatter graph of objects than, say, Entity Framework models. LINQ simplifies their mapping.
• Views and data models can evolve much more independently.
• As a rule, it is easier to model the binding to a model with a flat representation, for example, with FK identifiers, than an entity model that expects fully materialized related objects.
• You don’t have to worry about accidentally discovering “secret” or whitelisting properties for updates.

Answer 2

You have no reputation to comment, but Craig is right. This is a variant of the Model-View-ViewModel template. There's a good article on this available at Los Techies .

The article also uses the AutoMapper code that pointed to mgroves so you can kill two birds with one stone.

Answer 3

I think this is a pretty reasonable approach. One thing that can help you is AutoMapper .

Answer 4

It seems that you have the advantage that the model contains only the information necessary for presentation, and not a lot of disgusting functions / values ​​of business logic.