ASP.NET MVC: Is it worth it?
You talk to God, you're religious. God talks to you, you're psychotic. - Doris Egan
Catchy title, eh? I’m asking it because I think it’s a legitimate question. I’ve been working with ASP.NET MVC for a couple of reasons:
1) Peer pressure: Developers who I know and respect have been telling me its “very cool” and beats “classic” ASP.NET WebForms by a mile. Some of these people are pretty smart. Some of them are a lot smarter than I am.
2) I have no choice. The current project I’m working on for my “day job” uses ASP.NET MVC along with other “very cool” things like StructureMap, Castle.Validator and a few other alt.net type goodies. (Side note: alt.net may not be so cool. I tried to sign in at their site with my OpenID and it wouldn’t accept it. I got some bullshit about not having a valid email address… Folks, that’s the FIRST TIME I’ve ever been denied an OpenID login!) Correction: a commenter below correctly stated that I needed to enable my email on my OpenId profile. Usually, what people do is that if your email is not provided, they ask you to enter it. Oh, well….
So anyway, over the last month or more, I have had no choice but to struggle my way along with two or three other developers who are more or less equally “Into the shark pool: now ‘swim!’”. Today things got so bad that I started pair programming with another guy. You know the concept: One PC, One Driver, One Navigator, and (hopefully) Two Brains. Actually we got a lot done mostly because the other guy was familiar with certain aspects of the framework (its the client’s framework) and I was familiar with other aspects. So in about 3 or 4 hours, I’d say we got about 15 hours worth of what a single developer would be able to accomplish – and most importantly, both of us learned new “stuff” in the process.
But here’s my take on ASP.NET MVC so far:
1) I think it’s very cool. I like the idea of separation of concerns. I like the more "OOP” approach to web development. You can do a lot with it –- but!
2) It has a steep learning curve. ASP.NET MVC is NOT the kind of framework that you want to have to use if you’ve been arbitrarily thrown into a new project where you must use it, especially if you’ve been handed a highly customized codebase from a client that you must use and which cannot be changed for both contractual and architectural reasons.
And – especially – if the project you’ve been handed has a short fuse, for whatever reason.
3) There’s a lot of buzz about avoiding ViewState and the “old” Postback model. I’m just not sure how valid all that stuff is. ViewState is a perfectly OK concept, it’s just that developers don’t understand it and consequently it is prone to abuse. ViewState, additionally, can be stored on the server very easily, so at least a part of this objection is moot.
4) “No Postback model”. OK, that’s fine. But have you looked at what hoops you have to go through to make MVC work? Why do you think they stuck TempData in there into the MVC Framework? And why do you see developers building custom server-side Session for their MVC projects?
5) Complexity: What you get in your View is almost totally dependent on what you do in your Controller. If you need to do “extra stuff”, then you need to write “extra code” in Controller methods. There just isn’t any way around it. Purists will say that’s the way it’s supposed to be (“separation of concerns”). I’m just not so sure I like that – yet.
Bottom Line: The jury is still out for me on MVC. I know there are a lot of purists out there who will call me a traitor. Too bad, guys. I’m not saying I won’t use ASP.NET MVC, I just believe at this point that if I had the luxury of crummy old WebForms I would have been able to produce the same quality app a lot faster, and it’s performance would be the same – or better – than in ASP.NET MVC. I still think MVC is cool but frankly, I don’t like going home from work with a splitting headache.
Labels: ASP.NET MVC
Social Link it!
PERMALINK 7:47 PM
10 Comments:
1) Agreed.
2) Also agreed. Webforms has a steep learning curve for certain scenarios. For example, working with dynamic forms.
3) Viewstate is a slight performance problem in environments that have limited upstream bandwidth. It can be stored on the server but that has its own problems and developers don't tend to do it anyway, so as you say, the point is moot. The viewstate / postback mechanism is a leaky abstraction required to mimic an event based environment. I am glad to be rid of it.
4) TempData has a very specific purpose: to make small amounts of data available to the very next release. This is necessary for the PRG pattern. All web MVC frameworks have an equivalent (in rails it is called flash). Used correctly it is not too bad.
5) RenderAction allows you to call a controller action from a view. However, I am purist enough to think that it is a bad idea. MVC makes controllers testable and views simple. The downside is that the controller has to setup everything upfront.
Thanks for writing this post. It will be interesting to see if you evolve towards or away from MVC.
Although more complex, it is easier than writing code in: Init, PreInit, Render etc methods. Plus there is no "magic" postback stuff that happens. So I love that, that I have full control over my process.
You are right though...you need to extend ASP.NET with all the cool stuff to get the best productivity.
I came to the same conclusion: MVC is an overkill.
I remember ScottGu articles and tutorials about ASP.NET 2.0 (in 2005), I remember how powerful and relatively simple they were.
With MVC it's the same ScottGu, but the complexity is way higher.
But this complexity didn't really add up enough to pay off for itself...
Completely agree with the statement about its learning curve. It has a lot of convention over configuration type of things which to a new MVC developer can be confusing. Sometimes its very black box and cracking open reflector is your only course of learning to answer that "What the hell is going on here" question.
However, once you've crossed that learning curve chasm and chased this rabbit down the hole you eventually see the flexibility that it provides. It may not be the answer for your quick little POC app, but it does work well for apps that must be flexible.
Working with Spark has also make things alot easier in regards to MVC (IMO) too.
I sometimes want to rip my hair out when working with ASP .NET Webforms, and the same goes for .NET MVC, just not as much.
I agree that it does have a learning curve but it is not as steep as Webforms. Once you start going with Webforms and you want to do something specific, it can be a real pain. Such as my disabled radio button not coming back in the form post.
@MPiccinato, I suppose one could make the case that if you started out cold with MVC and had never even seen WebForms, your statement would be refreshingly accurate. However for most developers, this is not the case.
The alt.net site requires an email address because it's the sites policy. You need to set that in your OpenId when supplied to the site.
@Hadi,
You're right I didn't have my email enabled in my openid profile.
Thanks.
Hmm,
I think ASP.NET MVC is bloat. MVP is much easier to impliment for ASP.NET.
~my 2¢
I much prefer ASP.NET web forms with MVP (in a separate assembly) than MVC any day of the week. The MVC framework only supports ASP.NET and with what I do I often have to extend my presentation layer to Winforms as well. I downloaded and played with every beta that Microsoft released, and I am just not sold on MVC framework.
Post a Comment
Links to this post:
Create a Link
<< Home