I am wondering if it would be a bad idea to have just 1 strongly typed viewdata that all of my views shared?  That way I can populate the parts of the ViewData that a particular view may need and easily render them in any view (as usercontrols) without having to re-write anything. 

IE: I have a MyAccount page that shows a Customer, their Orders, Shipping Information and Billing Information.  These are in different Controllers/Views and therefore each has it's own Strongly Typed ViewData (CustomersViewData, OrdersViewData, ect...).  If I want to render all of this together via a view in my MyAccount controller as UserControls I run into problems becasue each UserControl is looking for it's own ViewData Type.

 Does this make any sense?

It seems like a good idea but it will probably be heavy and can cause trouble if your not careful about checking for null data

 Wow. Am I understanding this to mean that you would have a class that contains all the properties of customers, orders, and all the other related stuff. Seems like there should be a better way of handling that. Is using viewdata that isn't strongly typed an option? Seems like that's the way you would want to go for this. Here's a wacky thought (not even sure if it's possible). What if you had a viewdata object that contained other strongly typed viewdata objects? I'm really just thinking out loud with this but maybe a solution like that would suit your needs? 

Good luck.

Yes so the viewdata class would be somthing like this (which just uses my types generated by SubSonic):

1    Public Class SharedViewData
2    
3    Public CategoryList As List(Of SubSonic.DB.Category)
4    Public Category As SubSonic.DB.Category
5    Public ProductList As List(Of SubSonic.DB.Product)
6    Public Product As SubSonic.DB.Product
7    Public CustomerList As List(Of SubSonic.Db.Customer)
8    Public Customer As SubSonic.Db.Customer
9    Public CustomerOrderList As List(Of SubSonic.Db.CustomerOrder)
10   Public CustomerOrder As SubSonic.Db.CustomerOrder
11   Public CustomerOrderItemList As List(Of SubSonic.Db.CustomerOrderItem)
12   Public CustomerOrderItem As SubSonic.Db.CustomerOrderItem
13   
14   End Class

Then in my controllers I only populate the parts of the ViewData I need for a particular view and I can use the UserControls in any view and and controller with strong typing and not worry about the wrong viewdata type being passed. I just don't know if this would lead to poor performance.

 I suppose if that's what you need then so be it. I would just offer this question, though. If you have your view data encapsulating all your objects, are you really still strongly typing anything? It seems the only benefit you are gaining is the ability to do ViewData.Category as opposed to (Category)ViewData["Category"].

Yeah, that's fine if it's what you're after.

It won't affect performance if you're only passing the data that the view needs (ie passing null in "unavailable" properties). If, on the other hand, you're filling all the properties of this object, even when the view doesn't need it, then yeah, you'll be somewhat less performant.

The only problem I have with this approach (I've considered doing this myself) is that the view needs to understand that certain properties are unavailable. Someone coming along to the view later might think that they have access to the other properties and be hit by an unexpected NullReferenceException. If the view received a customised object which contained only the properties that the view *should* have access to, then this won't happen. It's also like communicating information/intention to the person designing the view.

For me, especially with long term projects, the ability to convey information like that is a huge plus.

But, like I said, if it works for you then there's nothing wrong with this approach.

You don't have to worry about NULLs if you will apply Introduce null object refactoring.

 I forget, what's wrong with using a dictionary?

nagir:

You don't have to worry about NULLs if you will apply Introduce null object refactoring.

eeks dude! that sounds like an ANTI-Pattern.

there's nothing simpler than saying if (object == null) { ... }. I can see what they're doing .. but my gawd ... the empty classes that get created .. all the extra code .. hello support and maintence? oh well, each to their own .. and this is getting off topic. :)

I'm using a base class which derives directly from ViewData. This class holds the stuff I need on the MasterPage and the most common parts of all views. For specific Views I use classes derived from my class to which I add additional stuff intended only for this view.

Just a thought.
 

var someValue = ViewData.GetOrDefault<bool>("SomeKey", false);

MVCContrib helper extensions. It's not really all that difficult. You can pull the values for your view perhaps at the top of the page, and use the variable throughout if necessary. It never really feels like using a dictionary from then on.