views:

1590

answers:

9

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 all C#)
  2. Performance is critical
  3. I'd like to test as much as possible

My team has only used PHP for web development, but are very experienced with .NET winforms (so either way we have a learning curve). My concern is that some people have expressed concerns about ASP.NET MVC's scalability to large apps. But from what I read webforms have their own problems as well.

Should I be reconsidering webforms, or stick with my gut and use ASP.NET MVC?

Related:

http://stackoverflow.com/questions/247115/should-i-build-my-next-web-app-in-asp-net-mvc http://stackoverflow.com/questions/521388/from-webforms-to-asp-net-mvc

+1  A: 

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

David P
+2  A: 

This thread sums up the concerns on both sides pretty succinctly.

Peter J
+8  A: 

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.

Chad Moran
I disagree that developing WinForms is faster than MVC. HTTP is easier to understand (for web developers) than the intricacies of the event model. Something like databinding a page based on a user control's OnSelectedItemChanged event is a tiresome process in WebForms, but trivial in MVC/jQuery.
Peter J
That's a subjective comment. I said WebForms is faster for those that have developed with WinForms. A lot of developers will just "get it." Where as conventional WinForms devs don't understand a stateless context (ASP.NET MVC/HTTP).
Chad Moran
+3  A: 

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.

Will
Fantastic comment, thanks!
Jess
Nonsense - you can test in Webforms if you follow a design pattern like Model-View-Presenter.
Wayne M
Hey, brighteyes, if you're doing MVP you're not doing webforms. ASP.NET MVC sits on top of webforms as well, but you don't use any of the webforms model (such as the Page's load event). Laying MVP or MVC ontop of webforms != webforms. I didn't think that distinction had to be stated.
Will
You used Response.Write() in Page_Load when you started on ASP.NET?... you were quite advanced. A better "crappy code" example would be a couple <asp:GridView> with two <asp:SQLDataSource> and a <asp:Login>.. then checkout that viewstate
Radu094
A: 

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.

Wayne M
+1  A: 

No. One thing that the ASP.NET MVC has over ASP.NET Web Forms in terms of performance is that it doesn't make use of a control tree. The control tree consumes a lot of server side memory and keeps the garbage collector very busy on pages with many controls. I would argue that you would get superior performance from the ASP.NET MVC. The unit testing aspects of it are a real win to.

The flip side of this is that you can't use all of the handy out of the box controls that you get with ASP.NET Web Forms and you'll probably end up doing more client side JavaScript development so the initial development budget would probably need to be greater if you choose ASP.NET MVC over Web Forms, but you would have a superior solution for the long term.

James
A: 

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.

metanaito
+1  A: 

"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"

Upmodded for that quote!

Bart Czernicki
+1  A: 

ASP.NET MVC is not a problem for Enterprise, but neither is ASP.NET, Silverlight, etc. They are all UI technologies. The majority of your application logic should exist in libraries beneath the UI layer anyway, so pretty much any UI can be used.

  1. We need to use Microsoft technology
  2. Performance is critical
  3. I'd like to test as much as possible

Based on the above, ASP.NET MVC will work. But, you can move the code down below the UI and test. If your algorithms are below the UI, you can tune them without altering the UI. And, if the UI layer is very thin, the perf hit for the UI is negligible.

Gregory A Beamer
What? ASP.NET and ASP.NET MVC aren't UI technologies...
Matt H