Tuesday, 5 May 2009

My MVC Best Practices talk

I’ve given that talk in quite a few places, and always promise to post the slides on my blog. But in fact, I was secretly waiting for the VistaSquad video to be released.

Thanks to Ian Smith, you can now see it all, complete with slides and excessive arm waving.

Vista Squad: MVC Best Practices By Ian Smith
View in HD  Download Version  Visit Ian Smith's ExposureRoom Videos Page


Neil Mosafi said...

"Mocking gives you spots and you won't get a girlfriend"... ROFL!

Neil Mosafi said...

Using ReSharper aswell! Was this filmed in alternate dimension?

Sebastien Lambla said...

Hey I said I had opinions, I didn't say they were set in stone :)

Neil Mosafi said...

Nice one. That was a good talk, by the way. Lots of stuff that I've read here and there but (being that I've not yet had the chance to work on an ASP.NET MVC project) I've never seen it all in action!

I saw you used the ForEach extension method... what would you think of using a templated control such as asp:Repeater or asp:ListView for that? Do they even work in ASP.NET MVC?

Anonymous said...

Great video... but you're using the most terrible video player in the world. It refuses to let me fast forward or jump around - amongst a number of other basic things (where's the volume control!?)

Please consider fixing/replacing it! :)

Cyril Bioley said...

Indeed, but I don't think it's really his fault on this one. The embedded player comes from the external website that hosts the video.

Usage of web controls is discouraged with ASP.NET MVC (yeah, it could seem crazy the first time you hear it ;-)).
The question was asked to Phil Haack (PM on the ASP.NET MVC project) a few hours ago on Twitter :


Cyril Bioley said...

Ooops, sorry for messing your comments section ^^

The preview was nice actually.

Chris McDermott said...


First off great presentation!

I've been trying to work out how you implemented the PresentationModel as I think it's a really neat idea. I hate the fact that my controllers are littered with calls to get data that will be used to build a drop down etc... why should my controllers need to know this... what if I wanted to respond to a call to return Json instead of present a view these calls wouldn't be needed.

I guess you extended the view page and gave it a Presentation property which you retrieved from the ViewDataDictionary but how did you populate it... how did it find its way onto the dictionary?

Did you wrap an aspect around your controller? Or did you modify the Controller Factory in some way?

Also do you have one presentation model per view?

Any hints or direction would be really appreciated.

Alfred said...

is there a working example of the code that i can download from somewhere?

Sebastien Lambla said...

Sorry for the late publication of your comments, they disappeared deep into the google moderation malarchy.

The way it was implemented is reasonably simple: views are pre-compiled and resolved through the IoC container (by rewriting the view engine). From there, the base page class depends on the IPresentationModel interface.

That interface depends on T (the model) in the costructor. The trick here is simply to create a SubDependencyResolver in castle that resolve that model to whatever the current model returned by your controller is and you're pretty much done.

wilhil said...

Thanks so much for uploading!

I was at this talk (as an IT Pro) but I have recently switched to development and I remember your talk, but at the time, it went over my head!

I can finally appreciate and understand it!

Post a Comment