tags:

views:

811

answers:

4

Sometimes the overhead of creating a new model type is annoying. In these cases, I want to set ViewData, and the options seem to be:

  1. Simply set viewdata with a string key, and cast it out. This has obvious problems.

  2. Store the identifier (string key) somewhere (where? on the controller?) and cast it out on the viewpage. While solving one of the problems, I'm still casting, which is problematic, and kills type inference.

  3. Use the MVCContrib strongly typed Set/Get functions. These are nice sometimes, but if the type isn't very descriptive, say a boolean "IsNew", they don't work too well. It also kills type inference and it's still pretty much just doing a cast, so I must manually sync up the view and controller.

So, instead I'm thinking of using a phantom type to combine both the type and key identifier. It'd be equivalent to this psuedo-C#:

class ViewDataKey<T> = string

This would let me create identifiers in the controller like this:

public static readonly ViewDataKey<bool> IsNew = "IsNew";

With some simple extension methods, setting the data would be:

  ViewData.Set(IsNew, true);

Getting it out is just as easy:

var isNew = ViewData.Get(FrobNozzleController.IsNew);

Notice we don't need to specify the type of isNew, it's safely inferred. The key and type definitons are stored in one location.

Questions:

  1. Where should the key be stored? For "global-ish" ViewData, some common class works fine. But for View/Controller specific data? Is there any downside to putting it on the controller? (Apart from the long name of the controller?)

  2. Are there any easier ways, or things already built-in?

+2  A: 

I think this is what the model does in the MVC pattern. Why you don't use a typed view instead?

I believe you just make things more complicated by introducing yet another dependency between the controller and the view. I don't see any specific benefit in terms of line of code or something like that. You have to declare the existence of the variable, which you'd also do in the model class definition.

You don't get any significant advantage by doing so.

Mehrdad Afshari
You're right of course. It's just that sometimes, it seems to be extra work to add simple flags here and there. Perhaps they are even optional (the ViewDataKey could easily store a default.) It's just that creating a new Model for each view seems like a lot of overhead.
MichaelGG
+2  A: 

One idea would be to create tuples for a strongly typed view in cases where you don't want to create a specific view model class:

class SimpleModel<T>

class SimpleModel<T, U>

class SimpleModel<T, U, V>

Then make a strongly typed view, as usual. Now you have the advantages of strong typing without having to make a new class for every case.

.NET 4.0 has Tuple, etc., built in.

Craig Stuntz
Tuples could work for some really tiny simple things, but suppose you had "IsNew", "ShowFrobNozzleSelector", etc. -- all booleans...
MichaelGG
@michaelgg why so afraid to create a model - takes two seconds - even for small things ?
Simon_Weaver
A: 

I'd still use the ViewData dictionary, and instead of "casting it out" I'd just use ToString() and Html.Encode it. Why break the MVC pattern?

Dave Van den Eynde
A: 

I just put up a post covering this topic.

http://agilefutures.com/index.php/2009/06/mvc-strongly-typed-global-viewdata

Hope it's of use.

Regards

Tobi