Silverlight and ASP.NET MVC Don’t Serve the Same Master

Tuesday, January 19, 2010

contrast I’m flipping between MVC and Silverlight projects when a startling contrast starts to emerge. It’s not the obvious contrast between stateful and stateless. It’s a subtler contrast in design.

If you poke around in a new MVC project, one of the first pieces of code you’ll run across is the code to register the default route. It’s in global.asax.cs, and looks like this:

routes.MapRoute(
    "Default",                                            
    "{controller}/{action}/{id}",                         
    new { controller = "Home", action = "Index", id = "" }
);

This snippet relies on some of the recent features added to C# – extension methods and anonymously typed objects. It obviously draws some inspiration from Ruby on Rails, which builds on top of the dynamic, malleable Ruby language.

Compare that code to the code you’ll see when you open up just about any Silverlight control.

silverlight code

Well, you don’t actually see much code because the code is swept underneath a carpet of regions. This happens quite often in Silverlight, and I think it’s because developers are embarrassed to write lines and lines and lines of code to define a single simple property. It’s the elegance of RPG combined with the verbosity of COBOL.

public bool IsDropDownOpen
{
    get { return (bool)GetValue(IsDropDownOpenProperty); }
    set { SetValue(IsDropDownOpenProperty, value); }
}

public static readonly DependencyProperty IsDropDownOpenProperty =
    DependencyProperty.Register(
        "IsDropDownOpen",
        typeof(bool),
        typeof(Foo),
        new PropertyMetadata(false, OnIsDropDownOpenPropertyChanged));

 

I realize IsDropDownOpen isn’t just a simple property. It’s a dependency property, and dependency properties hold many great and magical powers. Data binding in Silverlight (and WPF), for example, is wonderfully feature rich and easy, but it comes with a price. Instead of writing one line of code …

public bool IsDropDownOpen { get; set; }

we need twelve!

The contrast isn’t in the number of lines of code, however. The contrast is in who the frameworks were designed to serve.

MVC is for Developers – Silverlight is for Tools

The MVC framework is designed for developers who write code. This fact is obvious in the API design and how the team fights for programmer friendly features like the new HTML encoding block syntax. The MapRoute code we saw earlier is just one example of many. The MVC framework took inspiration from platforms that are popular today because they favor convention over configuration and essence over ceremony. These are fancy terms for keeping things simple and readable.

Silverlight is designed for tooling. Visual Studio, Expression Blend, and other XAML, code, and art editors. I’m not saying we get rid of the tools. We need the tools for the feedback and capabilities they provide when building effects, animations, and irregularly shaped objects. But, it seems the developer’s life gets more difficult with the addition of every feature.

The Next 5 Years

I’d be surprised if another language doesn’t come along to become the de facto standard for the code behind XAML files. A language that is just as friendly to programmers as it is to XAML. A language that makes writing code for System.Windows fun, simple, and readable.  Maybe it will look like …

depprop bool IsDropDownOpen { get; set; }

… but smarter people then me can figure out the syntax. I just know there has to be something better.


Comments
gravatar JH Tuesday, January 19, 2010
Check out the MVVM(Model-View-ViewModel) Pattern. The trend you are predicting has already started to occur.
gravatar Scott Allen Tuesday, January 19, 2010
@JH: MVVM does a good job of separating concerns, but it doesn't take away any of the code needed for for things like dependency properties s and visual states.
gravatar Jeremy D. Miller Tuesday, January 19, 2010
Scott,

Could you try using metaprogramming w/ IronRuby to get to your "depprop bool *****" syntax? If you have to have all that CSLA-like noise code to feed the framework, maybe that's the answer to keep from destroying your code readability.

And *I* think the ASP.Net MVC framework has too much noise code for my taste anyway.
gravatar Scott Allen Tuesday, January 19, 2010
@Jeremy - I'm thinking along the same lines. Still getting my Ruby chops up to snuff.
gravatar Jon Galloway Tuesday, January 19, 2010
I think your main point is valid: MVC code is designed to be edited by coders, and Silverlight is designed to be edited (primarily) by tools.

However, you're stretching things a little here. You're comparing code in a Silverlight control with an MVC route declaration, which is pretty different. A route declaration is a one-time add to an internal route list, while control code does a lot of other things (UI updates, state maintenance designer support, etc.). A closer comparison would be between the code you actually end up writing more often in both Silverlight and MVC, which is in the ViewModel. Silverlight ViewModels can often just implement INotifyPropertyChanged, which is simpler to handle than DependencyProperties.
gravatar Eber Irigoyen Tuesday, January 19, 2010
that's the one thing I have NEVER liked about Silverlight, you'd think they would have changed that by version 4, but still not happening, there are a few .net libraries out there with similar capabilities that solve the problem much more elegantly, I don't know why we can't have the same in SL
gravatar Scott Allen Tuesday, January 19, 2010
@Jon - Sure, small example, but the MVC team takes advantage of many C# features to cut down code to the essence. I don't think anything in SL even uses an extension method.

The UI controls would be easier to express in a language that has delegation as a first class concept.

INotifyPropertyChanged is something I shouldn't have to write over and over again, either.
gravatar Tom Janssens Tuesday, January 19, 2010
I have never done any Silverlight dev, but seeing your example just begs for a generic "ConventionProperty" class implenting all necessary interfaces.
On the other hand, I am wondering why they did not use seperate files (like the partial Winforms.Designer files). Maybe the architecture does not allow it ?
What still bugs me is that we do not have a unified pattern for all .net dev (using modelbinders and icommand for example...)
gravatar Tom Tuesday, January 19, 2010
I agree, big pain. You went with dependency properties in your example instead of INotifyPropertyChanged, but there's a connect ticket about the latter.
gravatar pete w Wednesday, January 20, 2010
I dont do any silverlight/wpf programming anymore as of recent, but I agree with you and remember the dependency property coding was monotonous at best.

Check out Caliburn, it really cuts down on the repetitive coding involved with XAML

gravatar Mike Thursday, January 21, 2010
So I do a bit of silverlight development and I find that I often don't write my own dependency properties much, but I do use the INotifyPropertyChanged all over.

That being said, they really should have had something done for dependency properties. I don't really think that adding a language construct for a framework is necessarily a good thing (e.g. depprop keyword) however I would love a builtin attribute that would accomplish the given task.

[DependencyProperty()]
public bool IsDropDownOpen { get; set; }
gravatar sikat ang pinoy Friday, February 5, 2010
Creating silverlight on asp.net mvc are now easy. Thanks for the tutorials I like how you have presented the information in full detail. Keep up the great work
Comments are now closed.
by K. Scott Allen K.Scott Allen
My Pluralsight Courses
The Podcast!