The Grand Unified Framework Theory

Tom Janssens left a comment:

What still bugs me is that we do not have a unified pattern for all .net dev (using modelbinders and icommand for example...)

But, Tom – we are pretty close. At least as close as we should be, I think. With .NET there are plenty of low level patterns we can reuse regardless of the application platform or architecture. Stuff like:

• Asynchronous programming with events or the TPL.
• Object queries with LINQ.
• Resource management with IDispose.

At a higher level, XAML {Binding} and friends are taking over client-side development. WPF runs on the desktop, while Silverlight runs in the browser, on phones, and on the desktop, too. The only formality left for total unification is the merge of Silverlight and WPF into a single product.

On the server side things are different, but maybe not as different as they first seem. Take, for example, the following method:

public int Create(Employee newEmployee)
{
    // ....
    return newEmployee.Id;
}

This method might belong to an ASP.NET MVC controller, or it might belong to a WFC web service. We can’t really tell without more context. If the method belongs to a controller, than a model binder will go out and search the HTTP payload for information it can use to put together an Employee. If the method belongs to a service than a serializer will use information gathered from the payload to form an Employee. Underneath the covers one recognizes the soap:mustUnderstand attribute and one doesn’t, but there isn’t a significant difference in the programming model.

And I think this is about as far as we should go. The “one size fits all” framework never fits anyone well.