Is ASP.NET MVC a bad choice for a large enterprise project?

Question

We are about to embark on a large enterprise application. I am seriously considering using ASP.NET MVC because:

1. We need to use Microsoft technology (biz logic is

Answer 1

Everything I've read about asp.net MVC says that it is able to serve up more page requests than asp.net webforms.

I have some doubts about its stability and security though. Both of these stem from the fact that it's not even released and even with the RC we saw some changes to the framework. I am sure there will be more changes as time goes on and things are found. It's new so there are not really "best practices" out for it and there is a not a wealth of experience out there detailing the small issues or gotchas that you might run into.

I've been using it and it does result in smaller pages and faster performance. But there are so many things I can do in webforms that I have no idea how to do with mvc because mvc does not promote the use of the webforms controls.

Answer 2

I would say go with MVC if you need or want its features . If you are building a line-of-business application such as an ERP or CRM system, I would use Webforms; if you are building a portal or community wiki type site I would go with MVC hands down. Ultimately it comes down to preference and what exactly your enterprise application needs to accomplish.

Answer 3

ASP.NET webforms are heavyweight and drop a crapton of stuff on your webpages, both in html/javascript and serialized viewstate. I remember my first ASP.NET website causing the GC to blowed up because of all the short-lived objects being rehydrated from that godawful viewstate. Oh, when I was young and naive (i.e., 2 years ago)... You have to have a very good understanding of webforms to build scalable websites from them. Possible? Definitely. Easy? Not.

ASP.NET MVC is harder to code initially, but is SO much easier to develop than webforms. The hardest things to learn are 1) the conventions aka "magic strings", 2) Html + inline code aka ASP and 3) html forms.

With MVC, you can't get away with the state nightmare that is so common to webforms development, which means that means your webpages are meth-addict slim. It also means you have to code your state a little smarter. The code is also MUCH simpler and scales MUCH better than traditional webforms, imho.

Also, testing with ASP.NET is near impossible, due to the hard-coded and unmockable dependencies baked into the framework. ASP.NET MVC replaced all of these with System.Web.Abstractions members that are mockable wrappers around these badly-designed and untestable objects.

Run, don't walk, to MVC.

---

For the obvious-impared, if you use a framework that sits ontop of the ASP.NET framework, such as MVC or any other that you wrote or that somebody else wrote, OBVIOUSLY some of these remarks don't apply.

If, on the other hand, you code as early man did against the ASP.NET webforms model (e.g., Response.Write() in Page_Load), my comments apply.

Can you write code that's testable against ASP.NET? Sure. Can you do it without including special testing code you or somebody else wrote? Sure. If you have TypeMock.

Answer 4

My opinion: use ASP.NET Webforms.

Disable ViewState in the Web.Config.

There is no need to preserve state because everything you really need is in the Request object. Use Javascript in conjunction with AJAX for data retrieval to render your UI controls client-side.

Create serverside wrappers in the form of control tags for your client-side component renderer. This is how I've been working for ages now, and it's fast, reliable, testable and organized.

It does take some time to setup a decent framework for this working method, but eventually it will rule.

I rather have no spaghetti code like MVC. Been there with PERL/PHP and classic ASP.

Answer 5

Stick with your gut. ASP.NET MVC helps facilitate testing because almost the entire API derives from interfaces.

Answer 6

ASP.NET WebForms is very much like Winforms and allows for RAD (rapid application development). It's very fast to get something in no-time. Problem with this is testing can be a major pain and if used for anything public facing can mean some major issues with ViewState. WebForms can hold state making things like a wizard a breeze to use.

ASP.NET MVC on the other hand can take a little longer to develop with and requires that devs understand how HTTP works. It's a stateless architecture meaning each request is it's own little world and usually has no knowledge of previous requests. The framework also allows for high testability.

As far as performance goes they're probably the same because ASP.NET MVC is just a framework built on top of the existing ASP.NET architecture. Though for client-side experience I'd say MVC is a bit faster.

As far as scalability I would say they're about the same as far as technical goes. How as for using the API and integrating it MVC would probably be a bit easier.

The website you're using right now to ask this version question is built on ASP.NET MVC and they have 2 web servers and a beefy db server.