25

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:

Should I build my next web app in ASP.NET MVC? https://stackoverflow.com/questions/521388/from-webforms-to-asp-net-mvc

Community
  • 1
  • 1
Beep beep
  • 18,873
  • 12
  • 63
  • 78
  • 4
    This is not a dupe. The question referred wasking whether to use it while in beta, this is asking whether to use it for a large enerprise applications. Different questions. – Erik Funkenbusch Feb 20 '09 at 19:10
  • 1
    I'd be interested in seeing a follow-up comment from the author relating his choice and experience. I have been using MVC since beta and I love it. Most of our apps are small so I can't speak to how scalable it is. My feeling is that since it allows for a lot of client side processing (jQuery, Ajax, JSON) that it is easier on the server and would thus make it more scalable. – Roland Schaer Jul 25 '12 at 13:36
  • 2
    So far, our application has scaled VERY well. It's a pretty massive app (Millions of LOC, hundreds of views), and we've felt that MVC was the absolute best choice. I couldn't imagine doing this via webforms. – Beep beep Jul 26 '12 at 14:28
  • 6
    Hey, StackOverflow is build with ASP.NET MVC. What else is there to say... – kroiz Aug 05 '13 at 13:36

11 Answers11

30

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.

  • Nonsense - you can test in Webforms if you follow a design pattern like Model-View-Presenter. – Wayne Molina Feb 20 '09 at 18:43
  • 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. –  Feb 20 '09 at 19:05
  • 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 with two and a .. then checkout that viewstate – Radu094 Feb 22 '09 at 08:48
  • Is this still valid in 2016 ? – Anyname Donotcare Nov 08 '16 at 07:50
  • @AnynameDonotcare even more so. –  Nov 08 '16 at 13:48
  • @will :I'm still develop asp.net web forms ,and i'm afraid of the long curve of `MVC` learning . should i learn it (is it suit enterprise applications) – Anyname Donotcare Nov 08 '16 at 14:19
  • 1
    @AnynameDonotcare Yes, absolutely. Web forms are dying--note the direction MS is moving re asp.net mvc core. In the long run, it's a much simpler way to create a website. You just have to get rid of all your bad habits. –  Nov 08 '16 at 14:27
27

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
  • 12,834
  • 2
  • 50
  • 72
  • 11
    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 Feb 20 '09 at 19:10
  • 5
    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 Feb 20 '09 at 19:16
  • 1
    @ChadMoran: where did you say that *WebForms is faster for those that have developed with WinForms*. You didn't put any relation between the two. You just said that WebForms is like WinForms and allows for RAD. – Robert Koritnik Apr 03 '13 at 10:09
9

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
  • 16,870
  • 3
  • 25
  • 32
3

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
  • 12,636
  • 12
  • 67
  • 104
  • If you want to dynamically generated fields based on form definition data, I think web form will be an easier option. Since you can dynamically build the control tree, including controls, validators and etc. With MVC although it is not impossible, I think it will be a lot harder. – Kelvin Jun 11 '14 at 05:18
2

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

David P
  • 3,604
  • 3
  • 37
  • 54
1

Have used WebForms for years and never liked them. Now use Asp.Net MVC for some years and this is so much better. Certainly woud recommend MVC.

Asp.Net MVC has an excellent architecture and is open source. So if you would identify bottelnecks in the http processing chain you could fix it. Most time you would be able to fix performance issues using one of the many extension points provided by Asp.Net MVC, like Binders as an example.

citykid
  • 9,916
  • 10
  • 55
  • 91
0

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.

Erik
  • 23
  • 2
  • 2
    Totally disagree, MVC has a much better design and forces much better design of applications built on it. Have used both for a long time. – citykid Aug 15 '13 at 12:41
  • MVC was conceived by a guy who never worked a real job. It spawns the worst code practices. Logic is strewn everywhere, from the html to the server-side. It's not maintainable. Good luck stepping into someone else's mess, er, code. Btw, who the hell has time to test? Where are these jobs that allow for time to build unit tests? It's a unicorn from my experience. – LargeDachshund Jun 30 '17 at 19:30
0

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 Molina
  • 19,158
  • 26
  • 98
  • 163
0

"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
  • 3,663
  • 1
  • 21
  • 19
-2

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.

dtc
  • 10,136
  • 16
  • 78
  • 104
-3

If you're able to use stored procedures then you don't need a big middle-tier like those generated by MVC. All you have to do is pass XML to your stored procs through a simple HTTP handler, get results back from a stored proc, and convert the results to JSON. MVC and other middle-tier stuff only serves to make money for companies that sell IDEs like VS.

Experienced Developer
  • 9
  • 4
    Do you have any examples of companies that do this for large enterprise applications? I can't imagine writing a big piece of software without a decent framework to support it. – Beep beep Feb 03 '12 at 00:09
  • 3
    The only people I see recommending big powerful stored procedures are the database vendors. For everybody else it is a really bad idea. PL/SQL or T-SQL tored procedure code is nowhere near as powerful, flexible or testable as .NET. – Robert Nov 28 '12 at 18:22
  • @Robert i really don't understand the aversion people have against sql, it's ridiculous. Yeah orm is good and easy but things get tough you should think about refactoring your code towards sql where needed. stored procedures win from orm hands down ten times over. And if you prefer sql to object mapping take a look at oracle's ord. – bicycle Jun 11 '13 at 15:33