Musings on asp.net MVC

Feb 14 2011

ASP.NET MVC 3.

You know, for the web sites on the internets. It's all greek to me.

I have written very small WebForms applications, but I never really got the whole web thing. Honestly, it's just never interested me. I've never needed that particular skill-set at work, so I've never bothered to acquire it out of hours.

However, at the mvcconf recently, Scott Guthrie announced that PluralSight were releasing free training, for 48 hours only, and I'd been hearing good things about MVC 3, especially the Razor view engine (and hey! FunnelWeb is an MVC 3 app, so I should learn it a bit, right?). Unfortunately, the 48 hours has been and gone now, but I managed to get in whilst I could and was lucky enough to catch the full 3 and a half hours content whilst it was available.

I was glued.

This stuff was amazing - it really resonated with me. Scott Allen did a great job of explaining everything and the underlying subject matter really struck a chord.

At this point I tweeted about how much I liked the look of the technology, and got an interesting response from this guy

alt text

This is a good question, and I'm not sure I'm best qualified (based on my limited exposure to mvc) to answer it, but I thought I'd throw in a few starters...

1. Get out of band.

MVC is an agile (with a small 'a') technology for a few reasons: They have a contrib site on codeplex, and actively work with the community to fold ideas back into the product; They work on lifecycles that normal companies would think of as 'regular' (approx 9-12 months to put out a release), but by Microsoft standards these are insane. Silverlight (another out-of-band technology) does something similar.

2. Bake a pattern in.

MVVM was invented by John Gossman and the original WPF team. They came up with the pattern to leverage off the Binding class to decouple the View from its DataContext. An MVP Presenter needed an interface to the View in order to interact with it, but a ViewModel didn't, and MVVM became the accepted pattern for XAML development.

That's not to say that WPF does not support other patterns, like MVC (maybe using Magellan) or MVP, but by and large, MVVM is the standard way to do stuff.

That said, there is no 'baked in' way to implement the pattern. You want to use ICommand or INotifyPropertyChanged? Go write a class to help you, or - more likely - go download a 3rd party framework like MvvmLight or Caliburn and integrate that into your project.

But there is no 'guidance' in WPF, because the technology stack was created without a UI pattern in mind; whereas MVC works pretty hard for you in the background to keep you on the right path. There's a good deal of convention-over-configuration going on with stuff like Routing strategies and naming conventions - things that would add real benefit to WPF.

Imagine if - by default - your view could have either a parameterless constructor (like now), or a constructor that took a single object parameter that got set as the View's DataContext, so you could inject your VM into your View without needing a ViewModel locator, or associated plumbing.

Even better - imagine if the XamlParser used an IoC container to resolve objects as it does its parsing? A container that you could inject? That would be cool... Now I wouldn't need Prism at all, because the only benefit that Prism brings above a simple MVVM library (as far as I can tell) is the 'Regions' part of the UI. If I could just throw in standard UserControls, and use an IoC container to instantiate those controls carrying a ViewModel constructor parameter - that would be fabulosity covered in awesomesauce.

3. Improve the language, not the tooling.

Razor has stolen a good deal of the headlines for MVC, and with good cause. It has pitfalls - the fewer opportunity you have to write code in your view, the less likely your are to hide (hard-to-test) business rules in there, but by and large the 'less-is-more' philosophy of Razor works really well.

XAML is a language that was designed to be tooled - it's right up the in the name X.(a)M.L. The problem came when the tooling was laughably substandard. Don't get me wrong, I fell in love with WPF the first time I saw it, but the Visual Studio 2008 design experience was a good few steps backward from where we were with WinForms (from a drag 'n drop UI build perspective), and Expresion Blend didn't really solve it for me, personally - I still find it quite hard to use today.

Yes, I know Studio 2010 (specifically, Cider) has made a good number of improvements in this area, but for me, it's already too late... I write my XAML by hand because (a) I always have, and (b) the stuff that gets spat out the tools (I'm looking at you, Expression Blend) makes me cry. Real tears.

I would love it if WPF vNext took a leaf from the MVC team's book and came up with a 'Razor' of their own... a strategy to simplify the creation and legibility of XAML, without lessening its power as a declarative syntax.

Of course Razor would not be the solution itself - this is merely a wish for the WPF team to focus on this area.

Enough navel gazing

OK - that's probably enough for now. But that's my initial thoughts on the matter. I'd be fascinated to hear what you think, especially if you'd had any length of time with both technologies...

Posted by: Ian Randall
Last revised: 14 Feb, 2011 08:34 a.m.

Trackbacks

http://topsy.com/www.xaml.geek.nz/musings-on-mvc?utm_source=pingback&utm_campaign=l2 | http://topsy.com/www.xaml.geek.nz/musings-on-mvc?utm_source=pingback&utm_campaign=l2

Comments

Matt Hamilton

14 Feb, 2011 10:01 a.m.

I think you're spot on with your point about guidance and patterns, Ian. I think WPF now is at the point where ASP.NET was right before MVC came on the scene. It's "done" insofar as it has all the bits necessary to build a great *application framework". I especially love your idea of IOC support when instantiating views.

I'm not 100% sold on the idea of a "Razor" syntax for XAML. I hand code all my XAML (for better or worse) and I'm very comfortable with it. There's room for improvement, for sure, but you'd have to be careful not to follow Razor's path of making it easy to include logic in your view. I like the fact that XAML is entirely declarative and any "logic" is defined in terms of triggers and behaviours rather than embdedded imperative code.

I think the IOC support is the killer idea in this post. With that, we could have a project template that starts a new app with a nice MVVM structure and really ramp up that "blank page" experience.

Ian Randall

14 Feb, 2011 10:09 a.m.

Thanks Matt, and I agree that Razor would be a bad fit for XAML (sorry if I didn't make that obvious!) - But I have a nagging suspicion that brighter minds than mine could improve the language by retaining its power but lose some of the verbosity - especially in element style properties (setting Triggers in Styles, for example). Markup extensions help to reduce the noise a little, but then again, they add to the complexity...

It's a gnarly problem, and I don't have the answer...

Matt Hamilton

14 Feb, 2011 10:16 a.m.

A great example of reducing XAML's verbosity (and this is up on the WPF UserVoice site somewhere) is Style setters. Right now you have to do this if you have a complex value:

<Setter Property="Foo">
    <Setter.Value>
        <Bar />
    </Setter.Value>
</Setter>

... but other elements in XAML have "default" content properties that allow you to omit the property name when setting a value. If Setter had that, you'd be able to write:

<Setter Property="Foo">
    <Bar />
</Setter>

There are a couple of places in XAML where shortcuts like this would be really handy. I suppose for those who use Cider or Blend they're not a problem, but for us hand coders they're extra unncessary work.

Ivan Towlson

14 Feb, 2011 07:57 p.m.

Excellent collection of thoughts. I don't have much to add, especially after Matt's comments. On the verbosity front, one thing I have been wondering about is a JSON or YAML syntax for XAML. Such a thing would be reasonably easy to build, but the difficulty would be getting the tooling up to par (specifically Intellisense). A pre-processor would also open the door to extensions such as the ever-controversial 'lambdas in XAML' proposal (duly acknowledging Matt's point about how XAML should be declarative), better factoring of XAML into smaller modules, partials (user controls do some of this but partials seem more flexible and lightweight), etc.

But yes, the pivotal thing is architecture support -- in both the framework and the tooling. Make it easy to implement MVVM. (And part of this involves fixing Silverlight so it doesn't require so much code-behind to do what should be declarative stuff in the view.) That would be the big lesson to take away from MVC.

Ben

14 Feb, 2011 08:34 p.m.

Enough navel gazing. Stop using a dead-end technology and get with the program. All the cool kids are using ASP.NET MVC3.

Ian Randall

15 Feb, 2011 08:43 a.m.

@Matt - I love the idea of making better use of 'default' values - apart from the one you mention, how about

<ListView>
    <ListView.View>
        <GridView>
            <GridViewColumn Header="Name" Width="120" />
            <GridViewColumn Header="Phone" Width="140" />
        </GridView>
    </ListView.View>
</ListView>

Well, what is the <GridView> if not a <ListView.View>? Making the content the View property by default would give us:

<ListView>
    <GridView>
        <GridViewColumn Header="Name" Width="120" />
        <GridViewColumn Header="Phone" Width="140" />
    </GridView>
</ListView>

@Ivan - Let's not do lambdas in XAML. Hmm? Let's just not... But partials would be awesome - Creating ways to automagically inject a ViewModel into a View is one thing, but sidestepping it by saying 'this bit of XAML is merely an extension of that class, so use it's DataContext' would be even cleaner!

@Ben - you are an arse

Ivan Towlson

15 Feb, 2011 08:25 p.m.

I don't actually want to do lambdas in XAML per se. But an easier syntax for injecting converters, selectors and other 'bitty' bits of code would be nice.

Re your ListView example: trouble is, this clashes with ItemsControl wanting to allow Items as the ContentProperty. Which ListView will almost aalways use ItemsSource rather than inline Items, inline Items are common in ListBox and ComboBox scenarios. So I imagine the argument is that allowing ListBox to have immediate children while requiring ListView to spell it out as ListView.Items would be confusing. Or then again it might not.