Are Developers Lazy?

I have been watching the ASP.NET 3.5 Extensions with great interest. Of special note is the MVC framework that Microsoft is adding to ASP.NET. If you haven't heard anything about this framework I recommend you go take a look at the posts Scott Guthrie has made starting with this one. I'm really excited about the potential enhancements which are offered with this new framework. Yes, I know Monorail is nothing new, but something has always kept me from adopting it.

Of particular interest with the Mvc framework is the ability to easily test the majority of your UI code. This is something which today is near impossible. Plus, who hasn't been frustrated with the quality of the HTML which are generated by the ASP.NET WebForms? Finally a way to take real control of your web pages while still using the ASP.NET pipelines (or at least what is remaining of it).

What has really caught me by surprise though is the amount of complaining people are doing regarding the ControllerActionAttribute. Basically with the Mvc framework in order to expose an action from a controller (an action basically equates to the way a given URL interacts with the controller) you need to mark it with the ControllerActionAttribute. This is the default policy which Microsoft provides, and you can change it if you want to go through the many steps involved in re-working some of their components.

Developers have been seemingly outraged by this. Instead most developers (at least the ones who speak the loudest) seem to say that any public method on the Controller should automatically be considered a controller action meaning all public methods of a controller should be publicly accessible via a URL. Now, I may be in the minority here, but having public methods exposed from a URL is actually pretty scary, and I actually like explicitly specifying which methods are exposed to a URL and which are not. Not because I wouldn't be able to tell with just public methods, and not that I wouldn't be able to use it properly, but just from a sense that many developers mistakenly write public methods when they should not be public. A developer may not realize what the "magic" is which is taking place. By making it specific it takes very little time, and then there is far less chance of mistakenly exposing parts of the application that have no business being exposed.

Is it really that much work to mark a property as [ControllerAction]. I don't get it. It takes half a millisecond, and then everything is clear. After all, we do this same sort of thin with all of our unit testing frameworks don't we? Why not just automatically treat every public method of a test fixture as a test unless otherwise marked? The argument seems to hold there as well. I understand other Mvc frameworks have worked in this way where an attribute wasn't needed, but so what? Is it that we're lazy, or is it that we are resistant to change? If we're resistant to change, then it seems like this whole argument is moot since this Mvc framework is a big change already.

Maybe instead we're resistant to change so complaining ensues for a couple of months before we realize that there are actually benefits on the other side and then we quiet down for a while?

The really interesting part to all of this is that the people complaining about the attribute are the same people who complain about the designer and drag & drop "programming". Admittedly, I am also one of those people who hates the designer. This means that when it comes to writing their pages they aren't being lazy. They are taking great care of the final output and look of their application.

So if being lazy is not a problem while writing the HTML for your web pages (or views as I should say with Mvc), then why is assigning an attribute such a big deal?

--John Chapman