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

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.

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.