Ah, just now saw that his presentation was based on yours…thanks for the link!

in the original presentation I created, I introduce the concept of PresentationModels, a secondary controller who’s responsibility is to encapsulate the display logic out of the views and that receives the model returned by the controller, which solves nicely the problem of testable presentation logic.

You can see the original at http://developerdayscotland.com/sessions/09-SebastienLambla/mvc-bestpractices.pdf and http://serialseb.blogspot.com/2009/05/my-mvc-best-practices-talk.html

Do you want another controller that does login/logout functionality? We have our own way of doing it, almost unique per project…

@Simone

Yeah, we’ve started doing more of the “precalculated logic” as well, it’s turning out pretty nicely!

1 – actionfilters: what if the magic strings were not exposed to the developers but “hidden” behind a “widget” library?

2 – HtmlHelpers: yeah, I know, the helper pattern sucks, but I guess it’s better than sticking complex conditions mixed with HTML. That’s why the following best practice was to “choose your viewengine carefully”
Another option, which I prefer, is trying to avoid all conditions in the view, and have these conditions already evaluated in the ViewModel. And have the view only handle plain boolean values.

I think of the ViewData object as a box that I’m handing to the View that has everything it needs to get it’s job done. Inside the box are lots of other, smaller boxes. Each piece of the View layer (the actual View, partial views, master page) all know what they’re looking for in the box based on it’s type. Each one gets what it needs with out asking for it via it’s .Model property. Just declare your ViewModel type and you’ll get what you need automatically. You build this on the ViewData dictionary.

Hating the ViewData dictionary with it’s “magic strings” is pretty common but I think that it is wrong to throw it out the window completely. You shouldn’t be playing in it at a low level but building code on top of it that makes your access to the contents strongly typed can enable some really good composition scenarios. Use type names as keys and build some glue in your view engine and you can have great, declartive composition in your View layer just like in your Controller layer.

While ViewData["MyKey"] is pretty fragile, that doesn’t mean touching the dictionary is wrong.

We’ll still go RenderAction route, but we have a RequiresPermission attribute that’ll render nothing if the user doesn’t have permission. This was kinda tailored to our requirements, so it might not fit your situation.

@Ryan

That’s a pretty cool concept – we do something a lot more basic and hard-code (i.e., interface called IRequireInitialization ) But I still don’t like inheritance/composition in the view model, I just get annoyed with orthogonal concerns represented in one object, and with a mapping operation going on too, it might not work with how we set up our pipeline. I can definitely see the value of doing this approach though.

public class LoginBehavior : IBehavior
{
public void Apply(BaseViewModel sourceModel)
{
sourceModel.Login.CurrentMember = MemberContext.CurrentMember
.Present();
}
}

You end up with pretty good SOC for dealing with bits of the view model that are not directly the responsibility of the controller action.

But what if all the views should check on the current user’s permissions in order to render or not render some of their content. How do you handle logic like that?

Currently I have all my ViewModels inherit from a base ViewModel which has a property that can be checked for the user’s permissions and is being populated on every request by a custom Controller Action Invoker, but so far it has only given me headache and it’s much too fragile and harder to test (specially when a Viewmodel contains list of child Viewmodels and they need to have those data populated too)

What’s your approach to situations like this?