Question

I am wondering is it good practice to try to make a view that takes in a generic view model?

I am wondering this because someone mentioned that he was anticipating to have to do lots of duplicate code unless he started to make a generic view and generic view model.

So basically the views would be like just a set of controls. One view might have 2 controls(say a text-box and radio button) another view might have 50 controls on it.

They will all have the same look and feel(it just grows by number of controls) . Basically he was thinking having a view model takes in the object(domain object) looks at it and see’s 50 fields and renders the right control types.

I guess a edit template could be used to figure out the controls however I am just not sold on a generic view model.

I like generics and they can do very powerful things and in some situations they are good but I am just not overall to crazy about them and try to not use.

I find most of the time it may reduce duplicate code but sometimes it makes the code alot more complicated. Of course this could just because I am still a relatively new to programming and it could be still above my skill level.

The next problem I have with it is I think that view models should be as flat as possible and only expose data that is actually going to be used so people don’t start using properties that should never been in the view in the first place.

The next problem I have with it that it could just keep going if you have some complex object that has objects in it that has objects in it. It could go for a long long time.

Answer 1

I don’t see anything wrong with generic ViewModels. It is a good way to remove duplication and keep compile-time checks, as opposed to ViewBag.

Example:

Imagine you have a set of Model classes for Product, Category, etc.
Each class (ProductModel, CategoryModel) has an associated display and editor template, which generates appropriate view.

Now you want to construct a set of pages for view and edit.

I usually create a Layout (Master page in web forms) to render the common content (header, footer, menu, etc.)

Then I would create individual, strongly-typed views that accept as model ProductViewModel, CategoryViewModel, etc.

Now we need to define those view model classes. Each view model class should take an instance of ProductModel, CategoryModel, etc (which will be passed to the template). But the layout often requires some additional data (ie. selected menu, logged-in user name, etc). My solution is to create a generic ViewModel that encapsulates this duplicate data for the Layout:

public class EntityViewModel<T>
    where T : EntityModel
{
    public T Entity { get; set; }
    public string UserName { get; set; }
    public string SelectedMenu { get; set; }
}

Then you can easily create a ProductViewModel : EntityViewModel<ProductModel>, which contains everything the Layout need to render the page, and you can add there any additional, product-specific data.