On ASP.Net MVC (yes, again :-))

time to read 3 min | 580 words

As you probably know by now, I have been working on an ASP.Net MVC project for the last two weeks. Based on that, I think that I can base a pretty good opinion about it.

Are you ready for it?

[insert significant pause here]

I like it.

Now, just to be clear. I like it not only in comparison to WebForms. I like it on its own. In other words, I don't consider the ASP.Net MVC to be a default choice if all you have is that or WebForms.

The pros of using an MVC framework are well known by now, so I wouldn't go blathering about that. ASP.Net MVC certainly hits a lot of those points. Another benefit that wasn't obvious to me was the default view engine, which uses the same WebForms editor. This means that we get intellisense. That was surprisingly nice to have.

Unfortunately, the WebForms view engine is also useless for any intermediate to advance scenarios, because it only allows you to render directly to the response, and doesn't allow you to capture the output of views and partials and process them further.

Another problem that I encountered with the framework is that, to someone who has been doing MVC for years, is it extremely non obvious at times. My default mode of learning is to dive into the code, and in general, this has been a successful way of doing things across many projects that I learned. I don't really like it that I run into brick walls along the way with ASP.Net MVC, but I should point out that my thinking about how things should work is based on my work with MonoRail, and it is likely affecting my expectation about the way the ASP.Net MVC behaves. Even so, there are several design decisions made there that I strongly disagree with.

The most problematic issue that I run into with the ASP.Net MVC during the last too weeks, and the reason that I don't consider the ASP.Net MVC vs. MonoRail to be a coin toss, is that a lot of the code is internal.

Now, I didn't actually went over the ASP.Net MVC source code. But I did tried to do things with it and was blocked several times because some of the things that I wanted to do are internal (IBuildManager comes to mind as a repeated example). The obsession with internal, and the resulting limitations of what I can do with the framework, is a huge problem for me in just about any Microsoft product. In this project, I explicitly didn't set out to create any complex site. I built a very trivial data driven CMS. Nevertheless, I hit a lot of those internal API, grr!

Most of those occur when trying to do anything interesting with the web forms view engine. There is enough friction using that that is it worth dropping it (web forms view engine) all together, even with the bonus of having intellisense in the views.

From the point of view of actual framework, I found it pleasant to work with for most of the time. And the extensions points that are open are very useful (OnActionExecuting, OnActionExecuted are good example of that). I think that in order to really get the benefits of the framework, I am going to have follow Jeremy Miller's footsteps and rip out all the thinks that I don't care about and replace them with a heavily opinionated and customized version.

The good news is that it is possible, and without too much problem.