使用多个模型比使用ASP.NET MVC中的ViewModel有更好的方法吗？

Question

I'm new working with ASP.NET MVC 2 and one of the examples I'm following is the official ASP.NET MVC Music Store on codeplex.

In the example project they have this scenario: There are three models: Albums , Artists , Genres .

What is making me doubt is the way they treat their views, for example, when they want to edit an album it's needed to have the list of all artists and genres from the database, so they make a ViewModel called StoreManagerViewModel :

public class StoreManagerViewModel{
  public Album Album{get;set;}
  public List<Artists> Artists{get;set;}
  public List<Genre> Genres{get;set;}
}

This ViewModel is passed to the view, and allows intellisense and to see multiple models in the view.

This method seems like it would make me have a extra class for almost every relation in my model: If I have aa Discography class and I want to relate Artists to Discography, I would have to make another ViewModel like the above.

However, I don't like to have two properties inside the Album Method:

public List<Artists> Artists{get;set;}
public List<Genre> Genres{get;set;}

Is there a better way of doing this other than ViewModels? Is there a cleaner way?

Answer 1

All of the other answers on this page so far have left out one important concept of a view model, that it separates the data layer from the presentation layer, and removes the ability for the view to construct queries which could crush your db. Its not just about intellisense and sending multiple models to the view, although those are other pluses.

Say for instance you want to load up on your site the top 100 stack overflow users whose name starts with myNamePrefix . Then for each user you want to display a list of the tags in for which they have more than 10 upvotes for. You could just pass a list of Users to your view, and then call the .Tags property, which would then make a round trip to the db for each of your 100 users. This might be fine when the db resides on the same machine as the web server and you're only getting a few hits per day. But lets say you you're trying to serve up this data for various values of myNamePrefix every second. You could probably find some creative ways to cache results, but for the most part, its better to populate your view model with all the data it needs (in this case via a single query), and just have the view spit out the results. Remember, its the view's job to display the data, not to fetch it.

Answer 2

The reason they choose to create a separate ViewModel instead of using a Model already created such as Albums , Artist , or Genre is because all 3 were required. If only one was required such as Albums it would have been fine to transfer just Album or IList<Album> depending on the use.

In ASP.NET MVC the Model can be any object in the system that you want to send to the View. Even string , int , and any other base type.

In ASP.NET MVC 3 you can also use the dynamic keyword as your ViewModel, so that you don't even have to specify the type. However you should probably avoid this until it is a last resort, because it is always better to have a statically typed ViewModel.

Lastly, you don't have to specify a Model at all, you can set and pull information from the ViewModel dictionary. But this probably should be avoided for anything more complex than the most simple information, because just like dynamic it isn't statically typed.

Answer 3

The ViewModel is there for two reasons:

1. Intellisense support.
2. Instances where passing a simple model simply isn't enough for your view.

The ViewModel allows you to send multiple Models to your view in cases where it makes sense -- there are a lot of cases where one simple Model just doesn't do.

There are also cases where you only need to send one View to your model. Use it where it makes sense, and when you only need to send one Model to a view (and you don't care about intellisense) then only send one model to that view.

Answer 4

when you're using Linq to SQL, every model will have its children and parent loaded in the object (when your DB is good). So in that case the original model is very often all you need in an edit view or a create view. because your model will be made for you.

ViewModels IS the clean way.

the dirty way is using ViewData . well, 'dirty'. if you need a SelectList together with your model, using ViewData is not dirty, it's the best way in those cases.

Answer 5

There is another way. You could use ChildActions.

Child actions can be cached and each child action can be called from multiple views.

Using child actions can be a better solution if you have ViewModels that overlap. For example, if every view has a sidebar, you can render it using childaction, and since it's cached, db wouldn't be queried for sidebar's model.

This is just another way. Wich one is better depends on problem you're trying to solve.