A very common argument against the asp.net mvc framework is that people don't want to use server side code in the same place as you have the html code. Some say it makes the code unreadable or that it is a step backwards in development and closer to asp 3. In my opinion, this is a very thin argument that comes from developers that haven't even tried the framework. It is in no way like the old asp 3 days. The only thing that is close to it, is that you use code blocks to display dynamic data. And why is that less readable then using xml placeholders all over the html and use the code behind to populate the data? To me, maintaining a view that contain lots of literal controls and placeholders of any kind can be very hard and annoying when you have to go back and forth between the .aspx file and the code behind.

I agree that logic in the view between the html is hard to read. But why would you put that in the view? We have a lot of other places to keep that. But whats wrong with using a foreach loop to display multiple rows of data in the view? Isn't that view logic?

I decided to build two simple applications that displays a number of rows from a dynamic data source. I built one using the asp.net mvc framework and one using the asp.net webforms framework. Here is a screen shot of the mvc view:

And here is one of the webforms view:

This is a very simple example, but to me it shows how much easier it is to understand a mvc view then a webforms view. I think that a designer that only knows html and css would have a easier time changing the design of the mvc view then the webforms view. It is easier to see what is server side code and what is part of the design that the designer is changing. This makes it, in a way, more seperated, ironicly, when it is in the same place then if you split it in two files as in the webforms view.

I also decided to run a preformance test between the two applications. I published both applications to this server (the one my blogg is running on) and used firebug to see how fast each page was loading. I set EnableViewState to false in the webforms application, as I would not need it in such a view anyway. In the test I had 800 rows of data in the database that I displayed. This is not realy a real world scenario, but I decided to have quite a lot of rows to get some difference between the applications. The mvc view took just above 400ms to load in general, while the webforms view took about 570ms to load in general.

Now, you should not trust this test blindly as it is a very simple scenario that doesn't realy test what a real world application would do. I did it mostly out of curiosity to get a grip of the preformance differences between the two frameworks.

Personaly I would choose inline code blocks over xml placeholders any day. I think it leads to a lot more readable code. Of course you don't have to use the mvc framework to use inline code blocks, you can do it in the webforms framework as well.

What I'm trying to say here is that code blocks in the UI isn't a bad thing if you use it right. It can, many times, lead to a more readable html markup that is easier to follow. Just because we have inline code blocks doesn't mean that we are taking a step backwards in development.