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.

Solution 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.

Solution 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.

Solution 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.

Comments

[Darin Dimitrov]

you employ the MVVM pattern in an ASP.NET MVC application? Hmm, I would also be interested in seeing an example of this.

[chobo2]

Would love to see an example. I am not familiar with that pattern.

[chobo2]

@ Jakub Konecki - Could you show an example. I would love to see one at the very least and see how it would look(maybe it completely different then I then it would be)

[chobo2]

The only reason that I found for searching is where some guy said he had like 200 enties or something that where similar and did not want to make 200 separate view models and I guess views. I am not sure what I would do in that situation. Another point I forgot to add is how about data annotation validation. I am guessing you probably have to put that on the domain object and I think that's another no-no. stackoverflow.com/questions/2138951/… -the poster does not mention View Models but I am assuming he probably is using them

[Nick Heidke]

I didn't see the asp.net tags at first glance, I had assumed you were using MVVM with something like Silverlight rather than MVC. Do "viewmodels" have a place in MVC? I typically just see views and models as separate entities.

[chobo2]

So Entity is now the ProductModel or CategoryModel or is it the ProductViewModel and CategoryViewModel?

[Jakub Konecki]

@chobo2 - As you can see in the last sentence ProductModel : EntityModel.

[Andrew Barber]

I don't see anything in the question about including logic in the ViewModel.

[user2330678]

@Darin Dimitrov I am using viewmodels only for passing data from View to Controller and not viceversa. Also its page no, pagesize, search filters, etc, for reading, no add/edit/delete operation. Some Controllers need extra parameter like ProductCategoryId. Should I use inheritance or duplicate code in the new Viewmodel with extra fields?