Should I build my next web app in ASP.NET MVC?

Question

My team is considering building our next web app using the ASP.NET MVC framework. I am slightly hesitant, as are some others, because it is still only in beta. I really want to dive in because it seems to be a great way of providing clear separation of concerns and improving testability.

Should I take the plunge now, while MVC is still in beta, or hold off for a release candidate?

From some of the responses, I think I need to clarify my question a bit. My primary concern is whether to go with a product that's still in beta, not webforms vs. mvc. The concern is mainly because of the fear that we end up using some functionality in the beta version that gets changed / deprecated / not supported in the final release.

However, I do appreciate the perspective on webforms vs. mvc. It just doesn't get at the heart of my question.

Answer 1

If you don't have to put your app in production soon, yes write it in MVC. Here, we have a team working with MVC and planning to put it on prodution at jan/2009.

Answer 2

So far Mvc looks good, however I m a castle advocate I have used monorail in many production sites and it got me into learning about IoC and AR Cheack out castleproject.org

Answer 3

I prefer ASP.NET MVC to WebForms, so I would choose that, but you need to work out as a team where your core skill set is and whether or not choosing MVC will:

1. Create a better product.
2. Get you to market quicker.

Don't just choose it because it's new. WebForms is still a great choice, and you can write code for WebForms that's both testable and has clear seperation of concerns.

Answer 4

It's a pretty simple decision tree, really.

Choose ASP.NET MVC if you...

• Care deeply about URLs
• Care deeply about your HTML
• Want true separation of concerns
• Want testability through and through
• Want flexibility of view engines (ASPX, NVelocity, NHaml, etc)

Choose WebForms if you...

• Enjoy the stateful abstraction of WebForms (ViewState)
• Don't mind PostBack model
• Prefer components that you can "drag & drop" on a page

For me, the answer will 99% be ASP.NET MVC, because I think it is a much better match for the web. I think the ajax story is much cleaner as well, and I have complete control over my HTML & URLs. On top of all of that, I can test-drive my website (controllers) quite easily.

Yes, I know you can achieve clean URLs in WebForms, and you can have clean(er) HTML through Control Adapters, and you can achieve a level of testability with the MVP pattern in WebForms, but these are all off-the-beaten path approaches. With ASP.NET MVC this stuff is core. That's just the way you do it.

And don't worry about the preview/beta status. The team has always maintained that you don't need a go-live license to deploy it (even though they now offer one). It's purely additive on the existing ASP.NET Runtime.

It's like automatic vs. manual transmission. Pick one that makes you happy and run with it.

Answer 5

If it's not mission critical and you and your team have the time to learn it, why not?

Answer 6

I'd recommend giving it a shot.

We just recently released an e-commerce platform with MVC running the front end, and while there are some gotchas that you may stumble upon (Say, resolving Url's with anonymous types is currently far slower than using a RouteValueDictionary, was a surprise to me), it certainly feels like it was a lot easier to build a manageable system in MVC compared to our older WebForms apps.

If you have the luxury of choosing, then you should definitely have a closer look. The bugs that have shown up while we worked on it have all been fixed fairly promptly, and most things work well now, and it's starting to feel pretty complete.

But in the end, it's always a risk to take on an early beta product. :)

Answer 7

Unless your app is super simple, it's likely that MVC will be released before you go to production. That hardly matters though. I have been building on MVC since Preview 2. Each new version has contained breaking changes; however, they have not been very hard to track down and fix. It's very unlikely that by 1.0 you could create a mountain of code that would be toppled over by some breaking changes. Simply budget a few person hours to apply each new version.