ASP.NET MVC: Why your dislikes may be wrong
Wow, so I keep talking about how I want to write more, particularly now that I'm an "insider" working in Redmond, and yet it has been a month since my last post. But hey, I've been here two months and I just finally spent some time in downtown Seattle for the first time last weekend, so get off my case. :)
Anyway, as is typical in the professional world of software development, I've seen a great deal of debate about whether or not ASP.NET MVC is the second coming or a step backward. There are also peripheral discussions about what Microsoft sees as the future, but given the outright declaration of that guy with the red shirt and the fact that we've got new versions of Webforms and MVC on the way this year, I think it's pretty clear that you use whatever the best tool for the job is. Isn't it funny how that comes up with every religious debate about development tools?
In any case, there are a few themes to the online chatter around MVC that don't give it proper credit. I'm not suggesting that these are stupid people, but rather people who don't have the whole picture for one reason or another. This isn't an exhaustive list I'm sure, but it is noise that may prevent you from investigating the framework further, or inspire you to spread misinformation. There's a positive theme that builds up here, as you'll see.
ASP.NET MVC is too primitive.
Generally I think this statement is made in the context of MVC's lack of server controls. Some people don't like generating markup, particularly those who've enjoyed the drag-and-drop RAD nature of ASP.NET. Let's face it, when we first saw demos of ASP.NET v1 prior to its release, it looked a lot like VB6, solving problems around the stateless nature of HTTP and letting us build stuff quickly. Behold the editable DataGrid, right?
The thing is, I would observe that as time went on, people weren't using these features out in the wild, particularly with big, sprawling, public facing apps. (I'd like to see the DataTable class stricken from the .NET Framework.) Personally, I almost always used Repeater controls, or variations on them I wrote myself, so I'd have more control over how the markup was rendered. And I almost never used in-place editing either, partly because I wasn't building Excel on the Web, and partly because getting your head around the event model was sometimes a pain.
So MVC goes minimal on the UI end of things by rendering simple HTML via the HtmlHelpers, and there's a remarkably simple state bag to hold on to your goodies when your server side validation says something isn't right. That you can simply wire up objects to those helpers without all of the "MyTextBox.Text = myObject.Foo" and the reverse nonsense in event handlers is a huge time saver. Give it a try!
MVC is a step backward to ASP.OLD and spaghetti code.
This is a pretty huge perception problem. I have to admit though, the first time I saw it demo'd, I thought the same thing. I remember the horror of ASP and trying to debug it, and this looked the same. That was because I didn't truly appreciate what Model-View-Controller really meant. After reading through a Ruby On Rails tutorial and reading various articles about the MVC pattern, something clicked in my head and I investigated further. Then I drank the Kool-Aid® at various Mix conferences and I was hooked.
But back to the Italian food, the biggest thing that colors your perception is that there are a lot of really bad examples of what a view should look like. That doesn't mean that it's conceptually broken. Remember that the MVC pattern facilitates the famous separation of concerns, meaning a view should not participate in any logic except perhaps some very basic display logic (most often, looping through some enumerable set of data). If you see some example on the Internets of a view that is calculating salaries, or worse, hitting a database, politely post on that site: "MVC: ur doin it wroung."
It's a lot of work deciding how to split everything up.
Again, I think that's only true if you aren't doing it right. Admittedly, it takes some practice to decide where things go, but after awhile it becomes pretty obvious. If you're dealing with a view, ask yourself if it's doing anything more than displaying stuff. If you're dealing with a controller, ask yourself if it's doing anything more than coordinating what to show the user, and shuttling data between the views and the models. If you're dealing with models (which is a pretty nebulous umbrella term in a lot of texts), ask yourself if it's doing any decision making about what to display or how to display it.
Don't be intimidated over the many related subjects around this concern soup. Dependency injection isn't that hard to get down, and like anything it takes practice to fully grasp why you'd want to soak up its awesomeness (see: Loose coupling).
In fact, the "ah ha" moments really may not come until you've forced yourself to sit down and do an end-to-end science project. While I understand that test driven development is a huge leap that's hard to make, unit testing can make your life easier even if it's slightly after the fact. In order to unit test, you have to figure out how to decouple your bits. That subject is too enormous here to cover, so you'll have to take it on faith until you try it.
Ugh, but it takes so long to do everything "right."
Think about how much time you may spend debugging a code-behind or a custom server control. If we share any experience, it's probably around those hours we'll never get back. Now imagine that you have some tight model that just does what it does, probably interacting with a database (or rather an interface that in production happens to be a database). Imagine you have a controller that takes the request, feeds its data to the model, then sends the model's data to a view to be rendered. Each phase of that can be looked at in total isolation. The points of failure are much easier to narrow down. And because it can be looked at in isolation, each part can also be tested in isolation. The speed at which you can debug this arrangement is far greater than what you do in Webforms.
The bottom line is that MVC is just... different. I happen to be a strong advocate of it because it gets back to the basics of what HTTP truly is, without a huge mess of abstraction on top of it to hide the way it works. That's important these days, because we trust the browser to do more work than ever now. The framework also gets us thinking about (but doesn't force us) how to do things in a way that is testable, more maintainable, and ultimately, more simple.
If you don't think you like MVC, but haven't really looked into it, go check out the learning page on ASP.NET/mvc. Read the tutorials, view the video (that Hanselman guy is a trip).