How to decide which is right, WebForms or MVC when doing ASP.NET

Question

So I'm about to start of a small project for my sporting club for member registrations and I'm trying to decide between WebForms or MVC.

Allit will be is a user login and data capture forms (or and data retrieval), so I was initally thinking WebForms with FBA but I've wanted to have a play with MVC for a while and I was thinking that it wouldn't be too bad a choice.

But not really having a lot of knowledge of MVC I don't know if it'd be a wrong fit.

So what's a good way to decide if WebForms or MVC is the right choice?

Answer 1

Is this a critical, production level application or a small one-off? Can you deal with the extra time that the learning curve of MVC will take or do you need to have it done right-away? Can you afford to scrap the whole thing and start over if MVC doesn't work out? Are you willing to have the platform change (probably not much now that it's in beta) while you are developing? Is there another project that is less critical that you could use MVC on to learn it.

Depending on how you answer these questions, learning MVC on this project might be worth it. Personally, I think it is a better architecture, but a less mature technology at this point. It has certainly increased the testability of my web code. I expect to move all of my development in this direction over the next year or so, though I doubt if I will change gears in any of the projects that I have had under development for awhile. I've just started my first new project in MVC. I wasn't willing to commit to it until it went into beta and I think that it will be in production before I'm finished with the project.

Answer 2

IMO, MVC is the way to go forward. If you have the time to learn the MVC programming way (because you hinted that you wanted to play with MVC .. meaning, you haven't used it yet), then this would be an excellent opportunity to dig into the product.

The learning curve is not high if you have previous WebForms experience (which i'm guessing you do).

If you need to make a site really quick, don't care about what it is and the site will be small, then go WebForms. It's the quick and nasty solution (for my opinion only). WebForms work 100% perfectly well. All my sites have been WebForms and they are fine.

Summary:

• Got time and want to learn the best way to make sites: MVC
• No time or don't care: WebForms.

gl and hth.

Answer 3

Based on your comments to tvanfosson, it sounds like MVC would be a good choice for you as you listed your desire to learn as a reason to choose that technology. I doubt MVC will change drastically from its beta. So, this could be a good opportunity to learn a new tool. As for as WebForms being the "quick and nasty" solutions, I worry that is MVC propaganda.

Answer 4

We were presented with the same opportunity. After playing around with MVC for a few weeks, we discovered there were things we didn't fully understand, as well as, things that were going to involve some changes:

• Implementing a the Repository design pattern
• Html Helpers vs standard Web Form controls, like Repeaters and GridView
• Caching
• Whether to use the framework we currently use, Csla, or try to move to just Linq-To-Sql with partial classes to hold the business logic
• Complex classes and user interfaces that involved master-detail classes

We decided to continue playing around with it and wait until it is officially released and then write an internal application and see where it leads us.

Answer 5

I actually really like the WebControls methodology. A lot of people are saying that "when doing MVC it's easier to Unit Test". First of all you should anyway what type of methodology you're using have a clean separation of Business Logic and your UI layer. If you do that then you can Unit Test your Business Logic regardless of which methodology you're using. Sure it might be easier and "come out of the box" with MVC, but it's not some Magic Silver bullet which is the only road that leads to Rome...

Second of all you could use WatiN which makes your app testable in ways that are far superior to conventional Unit Testing. (note I don't mean it should replace Unit Testing, but in addition to Unit Testing it takes you to a level of security previously impossible to gain)

Thirdly, the web is stateless. This is because of that HTTP is a completely stateless protocol. This is exactly what makes the web beautiful, but at the same time very difficult to develop applications for. The WebControls methodology mostly fixes this completely by having concepts such as ViewState. This takes away a lot of the hassle when doing application development. Have a look at this Ajax Calendar sample which is mostly impossible to achieve with the same (small) amount of code in any other paradigm then WebControls (disclaimer; I work with Ra-Ajax myself)

Now have a look at Stacked (Disclaimer; ...which I also work with BTW) then realize that I have so far spent less then 3 days developing what you're seeing there. Maybe someone could peak that accomplishment with MVC, but I doubt it...

I think the WebControl paradigm is very beautiful. Sure it has lacks on some points, but guess what, so does everything. The only "Silver Bullet" that exists in programming as an art form is that there doesn't exist any Silver Bullet.

When that is said, I know that Grurrah is using the Castle Project's MVC layer in addition to a WebControl based Ajax library. So to mix WebControls and MVC might be difficult, but surely not impossible...

I think MVC has gotten a lot of "deserved" hype, but unfortunately also in that process a lot of undeserved hype too...! :(

Make up your OWN mind, don't listen to the MVC evangelists trying to convince you that they have found the "Silver Bullet" to programming for the web. And wat's more, don't believe me either! I too have an agenda (get adoption to Ra-Ajax)

Make up your own mind. Asking someone if you should do MVC is like asking should I eat apples or oranges... The only GOOD answer you'll EVER get is; "It depends"...

Answer 6

Webforms is an abstraction of the web for folks who come from a gui world. I find it has alot of advantages, especially in the RAD sense, but when writing big beefy apps you often end up painting yourself into a corner it is very hard to get out of (ie: everything to do with viewstate.)

The other problem is you sort of fall into bad practices with webforms. You should not be using drag and drop datasources, built in grid controls, and most definitely not have business logic in the code behind if you want something that is scalable and maintainable with a clean architecture. To do that in webforms requires forethought and discipline, because everything steers you in those directions.

By contrast, with MVC you sort of fall into best practices. It is more performant (the whole page life cycle/viewstate thing chews perf on both client and server), and far cleaner from an architecture point of view.

The downside is that you can say good bye to RAD, and you will actually need to have decent knowledge of css/javascript to make good looking pages.

It really comes down to best tool for the job, and the type of experience/knowledge you/your team has.