More ASP.NET MVC Puzzlement
I have been slogging my way through the MS MVC architecture. There are some good parts and some really hard to get used to parts. Some stuff just has me completely puzzled. For example when your used to setting an autopostback property on a drop down control, the need to have to hand code some js to do the same every time I want an autopostback gets old pretty quick.
I love the way MVC separates out the code that used to get thrown into the same code behind in web forms. It really shines in that regard. Who knows maybe it will have a positive influence on webforms apps in that regard.
For the moment my bottom line is that it takes a lot longer to write the same functionality in MVC than webforms. That’s partly due to the learning curve and partly due to the fact that there is more code to write. The fact that there is more code will be interesting to watch. Maybe in time people will find some efficient practices that will help to bring down the overall effort required. If thats not the case I wonder how someone would justify the cost of building a system one way versus another. And dont tell me to build it in MVC because webforms are evil. Thats nonesense. We have almost ten years of webform driven sites out there.
Lastly, for all those folks who are jumping on the “Viewstate is evil” bandwagon – which seems to be the same lemmings who jumped on Datasets as a DAO in 2002 – have a look at the following performance test. 6-8 requests per second for an MVC app is laughable. I sure hope that’s not the case presently. Its worth some internal testing to see. By the way, just on a purely subjective note, for the past year I have frequently spent time on MarketWatch. Since they switched to MVC I have noticed a small performance penalty. Purely subjective. Heck maybe its even a matter of browsers.