The scenario:

Given a blog application, with the following layout

with two possible usages – a post page:

and a homepage:

Let’s define the view model:

PostData:
  string Title
  string Body

PostView
  PostData Post; 

HomepageView
  PostData[] Posts

LayoutView
  Tuple<string, int>[] Archive
  Tuple<string, int>[] TagCloud
  string[] Similar

 

The views:

1. _Layout.cshtml – obvious
2. Post.cshtml – given a PostData instance will render Title and Body
3. PostPage.cshtml – given a PostData, will call Post.cshtml and then render “add comment” form
4. Homepage.cshtml – given PostData array, will iterate and call Post.cshtml for each post

How data moves around:

• Controller is passing PostView (or HomepageView) *along with* LayoutView to the views
• Post.cshtml should only see its parameters, not the layout’s (which are passed but are not interesting within the post template).
• same goes for the other views
• All views should be able to “see” a shared parameter named “IsCurrentUserAdmin”

Given that I want typed access to the view parameters in the view (for the sake of intellisense and refactorings), how would I model and pass the data around?

I’ve pseudo-code-grade written two options: the first is to use inheritence in the view model to achieve type-ness, on the expense of flexibility (composition is difficult with class hierarchy, and you need to be aware of and grab the viewModel instance in various places). The second is flexible (use the ViewData dictionary) but getting type-ness is cumbersome and partial (strings scattered around, casting needed etc.)

see https://gist.github.com/1272269 if the gist widget does not load in-place

I do have a solution that works for me

With the many years that I’ve been writing complex web apps using various ASP.NET frameworks and almost always with c# based, static-typed view engines, I have a solution that works very nicely for me.

But I want to be aware of the MVC3 canonical / textbox way

So for all you MVC3 ninja’s out there – please describe your way of doing it.

 

I will describe my approach in an upcoming post and I’d appreciate any input on it

My blog has moved to AppHarbor, and while doing that I also changed the engine for a completely custom thing (running on custom-y stuff like WebOnDiet and NTemplate), to a wee bit more conventional codebase based on MVC3 and Razor, with lots of nuget packages replacing custom code that I wrote myself.

The packages file now contains AntiXSS, AttributeRouting, Castle.Core (for my good pal DictionaryAdapterFactory), elmah, MarkdownSharp, mongocsharpdriver, XmlRpcMvc and XmlRpcMvc.MetaWeblog (awesome!)

BTW, expect a post on using the DictionaryAdapterFactory to make handling Controller=>View data transport truly awesome.

What’s missing here? IoC !

yeah I did not bother with that now. I have my tiny 15LOC thing and this blog does not need anything of this sort.

 

Some things might still break. Files I used to host for downloading would probably won’t work now. I will fix that soon I hope, time permitting.

 

note to self – reshuffle the tags here on the blog. I need to re-tag may entries. Maybe I’ll let site visitors suggest tags?

After reading Brad Wilson’s post on that, I thought to myself:

Brad is 100% correct regarding the way the CLR treat interface attributes, but this does not mean the users should not be able to use validation attributes on model interfaces

So I sat down to extend the model validation to do just that: (see https://gist.github.com/1163635 if it is broken here)

 

Now I know it is hacky – it should not go on a FilterAttributes() method. If I had access to the sources I’d have added a virtual “GetValidationAttribute” method on DataAnnotationsModelMetadataProvider… (hint hint hint)