12/31/2009

ASP.NET MVC – Do I Really Need It?

As a professional software developer, particularly of the Microsoft flavor, you get bombarded with “new stuff”. If you do not instill in yourself a certain discipline, you are sure to be brought down by the sheer complexity of tackling every “new thing” that is sent your way.

I say this from personal experience; I do not mean to be negative in any way in saying this. It’s just a fact of life. There are so many “CTPs” and new technologies being thrown at you that it is easy to succumb to “Beta-itis” – the debilitating compulsion to download and play with every new thing, to the point where your productivity as a software developer begins to suffer.

It’s even worse if you’re an MVP because when you go to the Summit each year, they throw a whole truckful of even more sexy new “Stuff” at you. Sometimes, its stuff that nobody else has seen before and you had to sign an NDA saying you wouldn’t talk or blog about it. Talk about getting excited!

ASP.NET MVC is an example for me. About a year ago, I was working for an IT consultancy and we got a new client who insisted on using their existing codebase which was totally based on ASP.NET MVC. I had to learn not only MVC, but StructureMap (which I really like, thanks to Jeremy Miller) and other cool goodies whose names shall go unexposed for purposes of brevity.

But during this entire exercise, it became obvious to me that I could have done everything they were doing using my perfectly good “Classic ASP.NET” skills. I could have minimized ViewState by keeping it on the server (and I am certainly not the first guy to write about this, here’s a newer one). In addition, in developing a smartphone based web UI for it, it became obvious to us that a lot of the “MVCness” was actually an impediment.

You could make the case for unit – testability, and I would respond that most ASP.NET applications get smoke-tested locally to the satisfaction of the developers before deployment. Don’t get me wrong – I am a big proponent of unit tests and TDD – having helped develop some 700+ unit tests for over 280 DAO’s and Model classes in a current project I am working on.

Purists will tell you that classic ASP.NET doesn’t offer separation of concerns, etc., and they are absolutely right. But classic ASP.NET also works fine, as long as it is understood and not abused by developers.

I’m hip with ASP.NET MVC – MVP buddy Rick Strahl says that his Codepaste.net site (which I think absolutely rocks) was his first venture into ASP.NET MVC. I commend him for it. But the fact is, it could have just as well been coded in classic “ASP.NET” and it would have looked and acted pretty much the same. You want JQuery? You don’t need MVC to use JQuery.

The bottom line is, after a year or more of having been exposed to ASP.NET MVC – and especially seeing various developers putting out their own MVC implementations that do not even rely on the Microsoft engine, because they feel it is flawed – I still remain unconvinced. Read the forum posts and see how much pain the average developer goes through to adopt this -- to do something they already know how to do.

I think the lesson learned for me is to carefully consider new technologies and spend some time objectively determining if they are right for you, rather than “jumping on the latest bandwagon” due to peer pressure. You may decide that you do like a technology, but you want to wait a while before you jump on.

I use LINQ, Entity Framework, LINQ to SQL, lambdas, NHibernate, and much more of the new “stuff” because the benefits are easy to see and I’ve been able to make a determination in my own mind that the learning curve is worth the effort. I'm glad ASP.NET MVC is out there - it's a quality offering. But I’m still not using it. Flame me if you will, I remain unconvinced.

NOTE: Interestingly, Donn Felker, whose work I particularly admire,  has a more recent post that is very similar to this, featuring a real-life example of his own. I hope you’ll read it. Bottom line? Get the job done, get paid, and go home to spend time with your family. Even “Mr. ASP.NET”, Scott Guthrie, has something to say about the controversy. His bottom line? “Respect the choices other people make”.

WebForms isn’t going away anytime soon. As a framework for developing ASP.NET applications, it has evolved into a rich set of tools, controls and features that share more of the same “pieces” with ASP.NET MVC than many developers are aware of.  So if you’re an MVC purist and you feel that WebForms make you feel “dirty”, knock yourself out. You aren’t going to impress me.

Have a happy New Year, do good, and be productive.

13 comments:

  1. I have the same thoughts towards ASP.net MVP that you do, although I'd still use it for the following reason: it's much easier to pick up for future developers.

    I like the separation between all the layers making it visually easy to pick up.

    I could make the same argument about Linq to SQL as well, I could do the same stuff with traditional ADO.net, but sometimes I like the elegance and brevity of using Linq to SQL.

    My only issue with ASP.net so far is that I believe it was a ripoff of Ruby on Rails, the similarities are too hard to miss (and I'm not just looking at the MVC architecture)

    The other thing is that traditional ASP.net is such a great architecture and environment, to go to MVC sometimes is not a step forward.

    All in all, I think you make a good point, but let's not throw ASP.net MVC in the trash yet, I think the concept is quite good and clean.

    ReplyDelete
  2. @Mark, the RoR rip-off is a good thing. Not everything should be reinvented, RoR has a head start being the first to the market, and it would be really stupid to rename wellknown concepts.

    @Peter, I agree with you that ASP.NET can do whatever MVC can do. After all, ASP.NET MVC is a subset of ASP.NET.

    The objection I have to ASP.NET is that too many developers refuse to recognize the bad parts and start to bend the framework in unfortunate ways. I have seen to many examples of dynamically loaded user controls, session state exploits, misapplied view state, abused event handlers and whatnot going awry.

    ASP.NET remove many of those things by default.

    I haven't tried to target multiple clients, so I can't comment on that.

    ReplyDelete
  3. It's so embarrassing to discover my own typos. It should, of course, have been:

    ASP.NET MVC remove many of those things by default.

    (but you figured that out, right?)

    ReplyDelete
  4. I agree that it can be a little bewildering trying to keep up with every new technology out there. I prefer to give most things some time to mature and gain wide acceptance instead of instantly embracing everything like so many programmers/bloggers. I think that's one of the ways I've changed since I was a younger developer. Chances are that flashy new platform, language, library, etc.. is not going to change your life - most things are just small improvements on their precursors.

    So when I considered learning the new MVC way of doing things, I found the reasons for switching, other than testing, weak or contrived:
    http://stackoverflow.com/questions/390693/does-anyone-beside-me-just-not-get-asp-net-mvc

    However, I was not entirely satisfied with WebForms so I gave MVC a try anyway. I find that I am now doing things more the MVC way in my existing WebForms projects and often wish I could just rewrite things. When I am in MVC the only thing I really miss from WebForms is the use of controls that do their own data access. For me that is probably the clearest indicator that MVC is an improvement.

    I think my MVC exposure has at least made me a better WebForms developer - something that is probably occurs with other developers too, even if they decide to stay with WebForms.

    ReplyDelete
  5. shima2:29 AM

    I really don't know how to thank you, your blog saved me, it's exteremly useful.
    thank you so much

    ReplyDelete
  6. @shima, I have no earthly idea what it was my UnBlog "saved" you from. But, you're welcome!

    ReplyDelete
  7. I dont' really blame you for not giving it the time of day. It's less than 1 year from it's 1.0 release. There are lots of VB 6 programmers who still haven't adopted .NET. In fact, uptake on .NET really took off with .NET 2.0.

    MVC isn't a replacement for WebForms, but more and more ASP.NET development benefits from routing, web forms, and controllers. All of it can be used together now quite well. In fact, you could even put a controller in front of existing web forms pages. It's another featuer of ASP.NET in my book. There are also people who have told me that Lambda expressions (closures) are confusing, so they aren't using them yet. No problem. Good post.

    ReplyDelete
  8. Congrats on your new book, Jeffrey. See you at the Summit!

    ReplyDelete
  9. I currently work in both webforms (albeit using the Model View Presenter pattern) and ASP.NET MVC frameworks. I wouldn’t use WebForms without some form of view pattern over it for anything but the simplest projects.

    When I switch from working in the MVC framework to WebForms I see the limitations and artificial schematics that webforms impose on the HTTP paradigm. The term that I have heard, once refuted, and now wholeheartedly embrace is that webFrms is a "leaky abstraction."

    My first thoughts of ASP.NET MVC was that it was a "step back" to classic ASP, but after working with it for the last year (three projects) I no longer feel that way...Since you following the request/response HTTP paradigm closer, it is similar in some aspects to classic asp, however the similarities stop there (ok, except for the inline mark-up maybe).

    I chose MVC over WebForms for the following reasons: extensibility, ease of use, convention, testability and tighter “web fit”

    ReplyDelete
  10. Anonymous8:24 PM

    Thanks for the link Peter!

    The blog was updated with a new liNK: http://b.donnfelker.com/2010/01/22/mvc-vs-webforms-stop-it/

    ReplyDelete
  11. This comment has been removed by the author.

    ReplyDelete
  12. This comment has been removed by the author.

    ReplyDelete
  13. Anonymous4:16 AM

    I've got a chance to use ASP.NET cache a way back and found some limitations in it. It was good for my app as far as performance was concerned but when it comes to scalability issues; it came up with problems, even Microsoft has realized this factor and they all ready have introduced Velocity which is complting with some exiting distributed caching products like NCache. After this experience, now I am going to use ASP.NET MVC for the first time. Let’s see what’s happened now but I keep my finger crossed.

    ReplyDelete