Generic View Models?

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.

Answer 2

Personally I avoid using generics in view models. I agree with most of the reasons you mentioned against them and particularly this one:

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 idea behind view models is that they need to be specifically tied to the requirements of a given view, not making them general (/generic) as your domain models are. I prefer duplicating code in view models compared to having some generic monster reused all over the views and partials.

And even in cases where you need to generate dynamic forms and controls you don't need to use generic view models.

So, unless you have some hyper specific scenario (can't think of any at the moment), it's probably a good thing to avoid generics in view models.

This being said, don't rule them out completely, if you feel that there is a situation in which generic view models could be useful don't hesitate to present it here, by explaining the scenario and showing all the code so that we can discuss it.

Answer 3

As far as ViewModels go, I typically have all of my ViewModels inherit from a BaseViewModel that exposes methods that aid in implementing MVVM. If you'd like to see an example, just comment below.

Answer 4

I really do not like puting business logic inside viewmodel. I think that besides regular properties and error handling inside constructor nothing should be in view model. It makes much cleaner code, and you can more freely make additions to view model. If you have to much duplicated code you can isolate it to separate viewmodel and then nest it where you need it. This way you also have only what you need on your view.