C# – Strongly typed ASP.NET MVC ViewData extensions – where to put identifiers

asp.net-mvcc

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?

Best Answer

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.