From WebForms to ASP.NET MVC

Question

This question is for anyone who has significant experience using ASP.NET WebForms who has made the switch to ASP.NET MVC.

• What was your business justification for making the switch?
• Do you consider the MVC platform to be mature?
• How long did it take for you to be productive using MVC (say 80% of your previous WebForms productivity levels)?
• Have you encountered any significant pitfalls using MVC (either architectural, debugging, static UI or AJAX related)?

I am really looking for objective answers based on real-world experience, rather than answers that simply evangelise MVC.

Answer 1

I have used webforms for years when doing web programming, however MVC isn't a replacement for webforms. MVC is an additional tool in the asp.net toolbox.

IMO the learning curve for MVC is null if you can understand the pattern (it's extremely straightforward). However I would not recommend you abandon any current or future webforms development in favor of MVC without reason. I feel they both still have a place and usage.

I know this doesn't satisfy all the conditions of the request, but I really feel that I had to say this. It's kind of like "Don't throw the baby out with the bath water."

Webforms still has and will continue to have use, as will MVC.

I wouldn't consider a paradigm shift to MVC from webforms as a whole, more on a per project basis.

Edit: Answers to the actual question...

1. It was easier to implement the particular project using MVC and provided to be a learning tool for the platform.
2. Fairly mature. At least mature enough to use for production IMO.
3. Not long at all, but applying current knowledge to a fairly simple design is trivial.
4. Not in comparison to webforms yet, IMO the ajax interaction with MVC makes rich client apps more fluid to develop and use.

Answer 2

For us, the business justification was made after we delivered our first proof-of-concept jQuery/MVC integration. It's been three months now, and I haven't touched a single WebForm (and won't again, if I can help it.)

The beauty of an MVC architecture compared to WebForms is apparent from the first time you write an application:

• No more hoops to jump through during the "postback lifecycle". (i.e. no more wondering when your dynamically-added dropdown will be available for databinding after a postback.)
• Instant productivity: your development team is already familiar with HTML and javascript. MVC allows you to leverage that knowledge immediately, without added layers.

For 90% of scenarios in the past months, the MVC solution was delivered quicker than it's equivalent WebForm would have been.

Answer 3

• What was your business justification for making the switch?

Separation of responsibilities makes for easier to maintain code, less time to tweak, debug, test, and add new features.

• Do YOU CONSIDER (as in - the person who is answering) the MVC platform to be mature?

The MVC pattern has been around since like the 70's, The .Net implementation for the most part follows all the rules so it SHOULD be just as mature as any other UI framework that has been around for 40 years. ;-) -> ( Insinuates humor - that's for Bobby )

• How long did it take for you to be productive using MVC (say 80% of your previous WebForms productivity levels)?

The major difference here is that if you were using any 3rd party UI widgets/controls for Asp.Net Web Forms then you're probably going to want to consider using more client-side technology widgets in place, and that ramp-up time may take a while. The cool with .Net MVC though is that you can start out by using a mixture of Asp.Net and .Net MVC so that you don't have to ditch your current UI framework. Therefore, productivity should only be affected by how quickly you want to move to an MVC only UI tier.

• Have you encountered any significant pitfalls using MVC (either architectural, debugging, static UI or AJAX related)?

None yet, but I made it a point to really understand how the MVC works underneath the covers before I started to implement it.

Answer 4

** What was your business justification for making the switch? debugging, static UI or AJAX related)?**

• Testability. The testability of MVC is MUCH better. The fact you can Mock all the intrinsic objects is huge, the way they've structured ActionResults, etc.
• The pretty URL's. I know you can do this with WebForms and a re-writer, but it seems better/easier to do it in MVC.
• The MVC pattern is well known, even devs that have never done .Net know about MVC, so they can slot in a bit easier.

** Do you consider the MVC platform to be mature? **

• I've had two prod sites running in MVC since Preview 1 (over a year) There hasn't been anything that has gone bad because of this, so I do think now that it's in RC1, it's mature enough.

** How long did it take for you to be productive using MVC (say 80% of your previous WebForms productivity levels)?**

• I'd say it took about 2 months to get as productive doing MVC as WebForms. You have to get out of the WebForm mentality, AND you have to realize you want to use your Models a lot. Keep your views as light as possible.

** Have you encountered any significant pitfalls using MVC (either architectural)**

• One thing that is not as nice as WebForms is the immediacy of finding stuff.
  
  • In a standard WebForms app, if you're on MyPage.aspx, you know you open MyPage.aspx and you can find your way.
  • With MVC, if you are on /MyPage the View could be called YourPage, so you have to find the route, find the view, etc. It's minor but annoying sometimes. The new tooling in RC1 should make this easier since you can right click in a Controller and go to its view.
• Using standard AJAX stuff feels much easier than using it with WebForms.

There are still apps that I think WebForms work out better for. If your app is a heavy form based app, the built in PostBack model makes a lot of that easier. But I enjoy MVC quite a bit, and I had been working with WebForms since .Net 1.0.

Standard disclaimer tripe to follow :) I think like anything, right tool for the right job MVC gives you finer grained control, the WebForm model has a lot more stuff right out of the box.

Answer 5

I'm actually making the switch now.

Business Justification

The business justification for making the switch is that it's 'too easy' to make binding (no pun intended) design decisions in Webforms development that keep the application from being easily extensible or from changing one of its features without throwing the baby out with the bathwater.

I list some of those things below.

Maturity

I consider the spirit of MVC to be mature, but ASP.NET MVC is making its progress. I don't think it's fair to call it mature when it's not been out over a year yet.

It's a whole new world, as they say. The paradigm shift itself takes a lot to get used to, and the common practices (I wouldn't call them 'good' practices) of ASP.NET webforms development are essentially chucked out of the window. For instance:

• Binding a Dataset or DataTable to a DataGrid (no layers)
• Forcing 'tiers'. There aren't quick and dirty solutions (well, there can be, but that defeats the purpose of MVC, doesn't it)

Productivity

It's learning a new paradigm, so it really was a logarithmic curve.

Pitfalls

Being forced to not rely on some of the bread-and-butter controls made it tougher, but when it finally freed up the UI layer to change on a whim without the underneath being affected? That made business decisions easier.

Answer 6

• What was your business justification for making the switch?

Redoing a website from scratch which was based on ASP (not reusing anything from the old site other than the business rules which are hidden amongst the spaghetti code). After looking at the overall site the only controls we would be missing (we use devexpress) are the grid and navigation menu which can easily be replaced by extJS, YUI, and jQuery. I also just got done doing another site using WebForms where an UpdatePanel and dynamic grid started to get unwieldy after a few versions. I moved to MVC to avoid that pain this time around so far I would say using MVC + jQuery has been 100x cleaner.

• Do you consider the MVC platform to be mature?

I've been using it since Beta and haven't run into any issues yet. But we're still a few months from release. I never ran into any framework bugs that sucked up a significant amount of time during the development of a website prototype.

• How long did it take for you to be productive using MVC (say 80% of your previous WebForms productivity levels)?

I've always inherited poorly architected WebForms projects so never had the opprotunity to get super productive in them. I was productive with MVC within a few weeks thanks to Rob Conery's video tutorials. jQuery is brain-dead stupid to learn.

• Have you encountered any significant pitfalls using MVC (either architectural, debugging, static UI or AJAX related)?

Developing a clean modular system within MVC where you can plugin a forum, CMS, shopping cart, etc. has been the only architectural snag. I suspect that problem will get solved within the next 6mo.

Debugging webpages in VS + IE has always been a pain no matter what framework. It just doesn't match-up to the ease of debugging a C# WinForm application.

Answer 7

My business justification was the perceived superiority of the approach. I had been gravitating towards more "webby" applications with Web Forms - getting to know my HTTP, dropping post-back, using lots of specialized handlers, etc. The biggest challenge I faced was not learning not what MVC was all about but grokking the exact responsibilities of each artifact in ASP.NET MVC. What helped quite a bit was that I adopted it very early and was forced to implement a whole ton of things myself - and then contrast them with the later source releases to see where I'd completely missed the mark.

I was able to switch my current project to MVC with little trouble have had little trouble thus far, and have noted a serious improvement in the overall design of the code I write. It's even improved the way I write (when I do) WebForms.

However, there aren't apps for which one tool is better than the other. There are no reasons MVC is less appropriate for modular architectures. I shudder to imagine sitting down to write a CMS, forum, or shopping cart in full-blown WebForms after using MVC. I just want to generate angle brackets, I'm not interested in step 384 of the rendering lifecycle pipeline process model factory provider.

Answer 8

stackoverflow.com if written with asp.net MVC. Scott Hanselman did pod cast with the creators part 1 http://perseus.franklins.net/hanselminutes_0134.mp3 part 2 http://perseus.franklins.net/hanselminutes_0135.mp3

Really interesting stuff

Answer 9

If you've ever run a business, then you'd know profits is about minimizing input while maximizing output. WebForms is ALL about that since it generates so much code for you and is extensible (partial classes). I believe Microsoft is supporting MVC because it is a well thought-out and well-established pattern. Webforms and MVC are complementary and have seen articles to have them work together.