Ah, so finally Microsoft has also taken the road towards the Model-View- Controller pattern. Scott Guthrie talks about it in his weblog. It was a matter of time ofcourse after the self- proclaimed success of Ruby-On-Rails and the popularity of unit testing. One of the most important motivations that Scott mentions in his articles are ‘seperation of concerns’ and ‘designed for testability’. Let’s take a look at these two:
Seperation of concerns. The tradition ASP.NET model, using WebForms, had already a form of seperation. Namely between the HTML template (.aspx) and the code-behind (.vb or .cs or which language you have chosen). However, often you still end up inserting a lot of UI logic and business logic in the code- behind. Mainly because it is just so much more convenient to have all your UI logic in one place, instead in both the .aspx and code-behind file. So it boils down to this; no, the .aspx and .cs are not really seperated. In fact, I often just see the .aspx as a more convenient way of declaring controls, instead of programmatically adding them in the code-behind. In the last couple of years I have barely done anything more in the .aspx except for writing the HTML controls. That is right, I _never _use the designer. It is a huge frustration to me and I feel I have no control, whatsoever. The development time you win by using build-in grid wizards and such is often minimal compared to the time you lose to get the html output correct in the end.
Seperation of concerns is a good thing. Because most importantly, it eases your mind since you only have to focus on one aspect at the time. The code tends to be more cohesive, more readible and better understandable. Besides that, you automatically gets a better reusability of the components you write.
Designed for testability. This is still a big thing not well done in development nowadays. It is just very hard to test the UI. That is exactly where the user comes in and where things get fuzzy. Difficult to automate and therefore difficult and time-extensive to test. The basic idea to improve testability is to make your UI as dumb as possible. Also known as a passive view. The layer that renders your HTML should be thin-sliced over and over again, untill it does nothing more than just rendering some tags around provided text. The idea is that you might have errors in this thin layer, but you minimize the change of this because most of your code will be in another testable layer. UI testing is difficult, but this might just be another step towards software of better quality.
When I read about the MVC framework in ASP.NET I did not see a lot of really cutting-edge features. Actually, I have already built most of these features into ASP.NET right now. I build my .aspx as passive views. I design my controller classes in another library. Which makes use of the object- oriented _model, _which is generated by an O/R mapper. I have been working with this design for the last year and it has been very satisfactory. I notice that I get less erors in my applications, not only because of the increased testability, but also because of a more seperated approach in the design which provides me a good overview and makes me feel in control.
The only thing thas been bothering me lately is the asp.net WebForms model. It is just a pain in the ass to create a lean and mean performant application with this model. Especially the viewstates put a huge burden on this. I think a lot of asp.net developers experience this, because it just is too easy to drop some controls, enable viewstate and do continuously postbacks. But it just adds too much overhead. That is why I am looking forward to the release of this lightweight framework. Not because it is very revolutionary, or that you can do things with it which are not possible today, but to get rid of all this extra drag you get with the WebForms model. The time has come to take back control!
Share this post
Twitter
Google+
Facebook
Reddit
LinkedIn
StumbleUpon
Email