Using Technology to Compensate for Lost Convection Currents

Working remotely has massive benefits that have been lauded for eons: no commute, flexible working hours, progressive working practices yada, yada yada; but it also has some major drawbacks. The main one that's been gnawing at me recently is the lack of Convection Currents of Information.

Being physically surrounded by like-minded developers (in an office) exposes you to these convection currents. You can't help overhearing John talking about the new API he discovered, or Sarah arguing with Mike about which Pattern would best solve problem X. When you work from home all you get is silence.

The great thing about these currents is that they are usually exciting, challenge you to change the status quo and stop you resting on your existing methodologies. It can be difficult to keep your saw sharpened if you lack day-to-day peer interactions.

I recently upgraded my phone to a cool new Windows Mobile device. The inbuilt RSS hub is now full with dozens of blog- and podcast-subscriptions that I can access anywhere, anytime. This is revelationary! Today I read Joel's post: 12 Steps to Better Code whilst out in the garden with the dog. Fantastic. And so little effort involved! I am no longer required to be at my desk if I want to learn.

And that really is the key: I needed a no-brain, easy solution to keep in touch with my peers and what they are doing today.

Just because you work remotely doesn't mean you can't be part of the conversation.

Polymorphic Limitations in Strongly-Typed ASP.Net MVC Views

Strongly-typing your views gives you nice, easy access to what ever view model your controller passes to it. Simple and powerful.

Unfortunately, though, there are some limitations.

1. Your View Model cannot be abstract.
2. Your View Model will only get POSTed back as itself.

The first point is fairly simple. Everything works until you POST back your view model e.g.

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Update(MyAbstractViewModel model)
{
    // Clever bits go here...
}

Calling this action will result in the framework throwing a MissingMethodException: Cannot create an abstract class.

The second point is a little more complicated. Let's say you have 3 classes:

public abstract class MyAbstractViewModel
{
}

public class ViewModel1 : MyAbstractViewModel
{
}

public class ViewModel2 : MyAbstractViewModel
{
}

Now you create a simple GET Action that returns a View (strongly-typed to MyAbstractViewModel).

[AcceptVerbs(HttpVerbs.Get)]
public ActionResult Index()
{
    MyAbstractViewModel model;

    if (something)
        model = new ViewModel1();
    else
        model = new ViewModel2();

    return View(model);
}

The view will render successfully. Unfortunately, our original POST Action will not receive either of the concrete classes - only the one the view is explicitly typed against (i.e. MyAbstractViewModel).

These are, obviously, not major issues but it does limit developers' creative freedom and the most elegant solution may have to be foregone in order to fit the framework.