tags:

views:

311

answers:

2

I've been reading the Professional ASP.NET MVC 1.0 book as well as reading other sources talking about using ViewModel instead of ViewData from within your controllers to Views. But then I see so many examples of ViewData being used in scenarios that are tough where there's no other way but to get something from ViewData. But then I read a book like Pro ASP.NET MVC Framework and all he talks about is only ViewData, nothing about ViewModel. So is ViewModel a very new concept or what?

I see that ViewModel is a much better approach but is it a solid alternative? I mean ViewData is so readily available to you in other things such as the HtmlHelper object where ViewModel is not. Or for example using it in a custom control (http://www.codeproject.com/KB/custom-controls/MVCCustomControls.aspx). So do I use a combo of both depending on different goals or what? What if I want to access the ViewModel in my Extension method for whatever reason? I'm lost here as to what path to take. I know that ViewData is not strongly typed but that you can set your view to specify the type and therefore make your ViewData typed but I just wonder. There is so much support for ViewData but I know ViewModel is a much more abstract and separated way to go as well as it being typed. I just don't want to cut myself short in scenarios where I will need to grab certain data such as the ViewData that is readily accessible from other objects such as the HtmlHelper class.

Thoughts? Standards? Experiences? Am I off a bit or do you just use a combo and still use ViewData in other circumstances than just sending data from your Controller to your View or what?

And If you're not using ViewData at all and instead using ViewModel with your controllers, it seems like an all or nothing in that you are using ViewModel and therefore ViewData has no purpose since you have not set it in with anything from your controllers so it has no use at that point?? Am I confusing anyone or way off here? Confusing the hell out of myself that's for sure.

+2  A: 

Well, ViewData is a pretty quick to implement method. However, there you're doing a lot of string literal passing which is usually not a good thing. You could solve that by using some string constants, which is what I do with Session variables, but I think here a ViewModel is a much better approach. Any time you can use ViewData, you could also use a ViewModel. The ViewModel doesn't have to be just your domain object; it could be a helper class that has not only a domain object but some extra properties specific to your view; that's why it's there. So with the ViewModel, you have the compiler helping you and clearly from an OO perspective, it is far cleaner than just passing in keys to a dictionary.

I think MVC here offers a good approach. It offers and quick and dirty (not necessarily a bad thing) for those who need to "just get it done" and a cleaner approach, both of which are quite easy to use.

If you haven't read Scott Gurthie's ASP.NET MVC Tutorial; I highly recommend it:

http://weblogs.asp.net/scottgu/archive/2009/04/28/free-asp-net-mvc-nerddinner-tutorial-now-in-html.aspx

BobbyShaftoe
I'm not talking about ViewData.Model. I am talking about an extra layer of classes that live between your View and Controller "ViewModels" that do the work to get certain objects from your model so that the controller can use them instead of your controller grabbing items from your Model layer.
CoffeeAddict
+1  A: 

Now view models are considered as useful programming pattern. Read this article by Stephen Walther, for example: ASP.NET MVC Tip #50 – Create View Models

Alexander Prokofyev