195

I know that Microsoft has said

ASP.NET MVC is not a replacement for WebForms.

And some developers say WebForms is faster to develop on than MVC. But I believe speed of coding comes down to comfort level with the technology so I don't want any answers in that vein.

Given that ASP.NET MVC gives a developer more control over their application, why isn't WebForms considered obsolete? Alternatively, when should I favor WebForms over MVC for new development?

P.Brian.Mackey
  • 11,123
  • 8
  • 48
  • 87
  • 4
    As a Java "observer" from the outside, I'm very interested in this answer as well. –  Jul 22 '11 at 17:19
  • Related to my question: http://programmers.stackexchange.com/q/35917/963 – Gulshan Jul 26 '11 at 03:29
  • 57
    @Darknight :\ that's highly biased and simply wrong. MVC is not for simple CRUD apps. I'd argue WebForms is for generic CRUD apps (i.e. database -> some shiny grid control). – Raynos Nov 13 '11 at 12:29
  • 1
    @Raynos ok, whatever makes you happy -> if you like MVC go crazy with it ;) – Darknight Nov 21 '11 at 13:16
  • 17
    @Darknight whatever makes you happy -> if you like WebForms go crazy with it ;) – Raynos Nov 21 '11 at 13:22
  • @Raynos, I use both, but I also know both has its strengths and weakness.. – Darknight Nov 24 '11 at 16:20
  • 16
    @Darknight You obviously have a poor understanding of MVC if this is your opinion... There are some huge sites built with mvc... do some research sir. – Robotsushi Nov 29 '11 at 18:44
  • 32
    IMO, never use webforms when you can use MVC instead. – scottschulthess Jan 15 '13 at 19:23
  • 10
    I'm not one to speak so this is just my opinion. After reading most of the answers I came to conclusion that the answer is just never. MVC is just awesome and the only drawback I found is that I keep seeing `;` at my webpage (If you're just beginning with Razor you'll get the joke). – MasterMastic Jan 24 '13 at 14:09
  • 1
    @Darknight you know this is an ASP.NET MVC site? The MVC pattern is one of the best things to happen to web development in a longtime Ruby On Rails (Twitter) (Base Camp) Java's Spring framework, to many PHP examples to even count. – Anthony Nov 18 '13 at 21:24
  • 1
    The problem is when a pattern is turned into a framework, that's my problem with asp.net MVC. You can use the same pattern and approach in web forms without the MVC framework. Since I originally commented (man this thread is old!) I've moved away from both frameworks. Its now mostly light services with pure ajax front end think SOA that I like :) – Darknight Nov 19 '13 at 15:35
  • @Darknight, StackOverFlow website was developed using ASP.Net MVC.. – Hassan Wasef Jan 09 '14 at 22:30
  • 1
    Lets put it this way, if you are building a house web forms are predefined construction modules and mvc are bricks. If you can make it happen using modules great, but usually you have to use bricks at some point. I would suggest go with MVC, always. Learning curve is actually not that bad. – John Sep 19 '14 at 14:23
  • I will just let go Webforms. MVC is the way to go. The main problem of Webform is Code behind , Code behind and Code behind. Below is a detail article which discusses the evils of code behind. http://www.codeproject.com/Articles/821275/Webforms-vs-MVC-and-Why-MVC-is-better – Shivprasad Koirala Oct 08 '14 at 12:00
  • In reality, you don't go with something obsolete. If you go and find a job, you will notice less and less webform jobs. This is another reason why that you want to go with MVC. – Jerry Liang Oct 30 '14 at 03:44
  • 3
    @Darknight "The problem is when a pattern is turned into a framework" Why would that be a problem? Or on the flip-side - how could you have any framework without basing it on some core architectural pattern? – Alex Dec 13 '14 at 08:23
  • "When to favor ASP.NET WebForms over MVC" - Never. Anyway, it's all about OWIN, Web API and SPA's these days. – mbx-mbx Apr 01 '15 at 12:41
  • I'm seeing rumblings that `System.Web` is too difficult to maintain and that feature releases for WebForms will be slower than they were in the past. Microsoft is pretty consistently stating that WebForms support isn't ending any time soon, but don't expect WebForms to offer the latest and greatest features. E.g., Microsoft promotes vNext has having near-realtime code updates, but I don't think you'll get this with WebForms. WebForms won't be dead any time soon...but I'd be hesitant to use it for new projects. – Brian Dec 21 '15 at 21:41
  • I continue prefer asp.net for enterprise and intranet aplicativos and use mvc for small things and public websites – pho3nix May 21 '16 at 19:43
  • Q: When to favor ASP.NET WebForms over MVC? A: When you have already handed in your resignation, hate your current employer and coworkers, and want to leave them a nasty farewell present. – Nathan Chere Jun 30 '16 at 07:16
  • @MasterMastic "MVC is just awesome and the only drawback I found is that I keep seeing ; at my webpage (If you're just beginning with Razor you'll get the joke)." - I'm on my second day of using Razor, and anything ASP related....and I don't get the joke. Can you explain please? – Honinbo Shusaku Sep 14 '16 at 12:30
  • Thinking about it, MVC is not a endgoal in itself something out of 2005, MS never intended to end up with it, now they rather see ASP as a modular framework, and in compliance with that, they evolved further their new kid in town is Kortana apps, apps that are no longer bound to IIS, but can run on linux servers as well, even android. I think its time to move on, and if possible skip older technology. From how i see kortana its less jinglebells more close to raw goal as ASP used to be. – Peter Oct 24 '16 at 21:43

19 Answers19

196

I developed ASP .Net WebForms applications for 3 years, and after one day of doing an MVC tutorial I was sold. MVC is almost ALWAYS the better solution. Why?

  • The page lifecylce is simpler and more efficient
  • There is no such thing as controls besides html controls. You don't need to debug your output to see what ASP .Net is generating.
  • ViewModels give you immense power and obviate the need to do manual control binding and it eliminates many errors relating to binding.
  • You can have multiple forms on a page. This was a serious limitation of WebForms.
  • The web is stateless and MVC matches the architecture of the web more closely. Webforms introduces state and the bugs you have with it by introducing the ViewState. The ViewState is automatic and works in the background, so it doesn't always behave the way you want it to.
  • Web applications need to work with ajax these days. It's not acceptable to have full page loads any more. MVC makes ajax so so much better, easier and more efficient with JQuery.
  • Because you can have multiple forms on a page, and because the architecture is driven by calls to urls, you can do funky things like ajax load a different form, like an edit form into your current page using JQuery. Once you realise what this lets you do you can do amazing things easily.
  • ASP .Net WebForms is not only an abstraction over html, it is an extremely complex one. Sometimes you would get a weird bug and struggle with it for much longer than need be. In many cases you could actually see what it was doing wrong but you are unable to do anything about it. You end up doing weird workarounds.
  • WebForms does not make a good technology for designers. Designers often like working with html directly. In MVC it's a view, in WebForms it's half a day of work.
  • As the web platform is evolving fast WebForms wont keep up. It's not aware of new tags or features of HTML5, it will still render the same stuff unless you get (often) expensive 3rd party controls or wait for Microsoft to issue an update.
  • Controls in WebForms limit you in so many ways. In MVC you can just grab a JQuery library and integrate it into your templates.

I know some of the issues above have been addressed to some extent as WebForms evolves, but that was my original experience. All in all I would find it extremely hard to find a business case for WebForms unless a project is already using it.

Tjaart
  • 1,871
  • 3
  • 18
  • 21
  • 6
    +1 for pointing out multiple forms. Plus the fact that the HTML webforms generate is most of the time not very SEO friendly (as in: large chunks of viewstate on top of the page) – jao Apr 03 '13 at 14:42
  • 1
    The most of things you mentioned here are not true (but I won't give you a downvote). Nothing prevents you to turn off the viewstate in WebForms and use ViewModels and if/for loops instead of data binding and server side controls. – šljaker Nov 27 '13 at 22:59
  • 1
    There's so many untruths in this answer I'm surprised it has 41 up votes. – DarrylGodden Dec 17 '13 at 09:59
  • 1
    As a developer who did some huge apps in WebForms and some good ones with MVC, I agree with most of the things in this answer. especially #8: `ASP .Net WebForms is not only an abstraction over html, it is an extremely complex one ...` – Mahmood Dehghan Jan 05 '14 at 18:51
  • 5
    I have to agree 100% with this answer. At the end of the day, WebForms makings doing things on the client side (html / browser) so much harder. You literally have to fight the framework to get somethings done. An aspx page ends up with so much more code due to server controls than a cshtml page typically does. @šljaker If you start turning off ViewState and avoid server controls, you've abandoned much of WebForms at that point. I don't see that argument as particularly convincing. – Andy Jan 17 '14 at 17:37
  • 2
    @answerer , you haven't pointed out the most important , **test driven development with asp.net mvc is very easier**,, and does it possible to do the same with asp.net ? – Vishal Sharma Mar 02 '14 at 11:25
  • 12
    You can have plain html controls in WebForms, no one force you to use Server controls. You can have full stateless Webform, no one force you to use ViewState. You can use full ajax and jQuery in Webforms, no one is restricting you from using jQuery. You can implement URL routing, no one force you to use static file base URL. Manually drawing a page with CSS consume the time as much as MVC needed. You can design HTML page directly on Webform. – mjb Jul 30 '14 at 10:02
  • 1
    But, however, IMHO, for programmers of WebForm, you are strongly recommended to learn MVC which makes you an even more better WebForm developer. – mjb Jul 30 '14 at 10:09
  • 5
    @mjb: If you don't use server controls, ViewState and so on, why use WebForms at all when MVC is closer to what you're doing? It's like driving a tractor to work but not doing any offroading or using the shovel/hoe or stabilizer bars. At that point why not just use a car? – Nelson Rothermel Dec 23 '14 at 02:04
  • 3
    @Tjaart It is not quite right that you cant have multiple forms on ASPNET page. You could have as many forms as you want in ASPNET page but you could have only one server form - form with runat="server" attribute. – angularrocks.com Dec 27 '14 at 06:37
107

Webforms vs. MVC seems to be a hot topic right now. Everyone I know touts MVC to be the next great thing. From my slight dabblings in it, it seems ok, but no I don't think it will be the end of webforms.

My reasoning, and the reasoning as to why webforms would be chosen over MVC, has more to do with a business perspective rather than what one is better than the other.

Time/money are the greatest reasons why webforms would be chosen over MVC.

If most of your team knows webforms, and you don't have the time to get them up to speed on MVC, the code that will be produced may not be quality. Learning the basics of MVC then jumping in and doing that complex page that you need to do are very different things. The learning curve is high so you need to factor that into your budget.

If you have a large website written all in webforms, you might be more inclined to make any new pages in webforms so that you don't have two very different types of pages in your site.

I'm not saying it's an all or nothing approach here, but it does make your code harder to maintain if there is a split of both, especially if not everyone on the team is familiar with MVC.

My company recently did three test pages with MVC. We sat down and designed them out. One issue we ran into is that most of our screens have the View and Edit functionality on the same page. We ended up needing more than one form on the page. No biggy, except then we wouldn't use our masterpage. We had to revamp that so that both the webforms pages and MVC pages could use the same masterpage for common look and feel. Now we have an extra layer of nesting.

We needed to create a whole new folder structure for these pages so that it followed the proper MVC separation.

I felt there were too many files for 3 pages, but that is my personal opinion.

In my opinion, you would choose webforms over MVC if you don't have the time/money to invest in updating your site to use MVC. If you do a half arsed approach to this, it won't be any better than the webforms you have now. Worse, you could even be setting this technology up for failure in your company if it's messed up, as upper management might see it as something inferior to what they know.

Cory House
  • 233
  • 2
  • 6
Tyanna
  • 9,528
  • 1
  • 34
  • 54
  • 14
    This is a good answer. I gave you +1 because your personal experiences are appreciated. But, this is failure due to a lack of experience/skill-set of the developers which I asked to avoid. I am not convinced that Microsoft would choose not to mark a technology obsolete simply because of a fear of the learning curve for MVC. This may be the case, but I'm not yet convinced. – P.Brian.Mackey Jul 22 '11 at 19:26
  • 6
    @P.Brian.Mackey - I didn't say that forms development is faster than MVC. You asked to leave that argument out of it. Arguing time and money to train your staff is a different argument. MS won't mark webforms obsolete for one big reason: Enterprise clients have spent years developing web clients in webforms and won't look kindly on having to invest time and money to update. – Tyanna Jul 22 '11 at 19:39
  • @Tyanna if you knew both equally well and were working on a new project, then what would be the reasons to favour webforms? – Raynos Jul 23 '11 at 17:54
  • 16
    @Raynos - If everyone on the team was proficient in MVC, and your company was starting a new project, then the only reason I could see someone choosing webforms is personal choice. – Tyanna Jul 23 '11 at 19:20
  • 3
    I know both technologies intimately. All my web projects are done with mvc and work at a company where I have free reign to do whatever is the best approach. I always chooose MVC. – Robotsushi Nov 29 '11 at 20:27
  • 1
    @Tyanna Sad as it is, I think Microsoft do not care that much about their customers, specially developers. They dropped .Net Compact Framework completelly in mobile development with Windows Phone 7, in favor of Silverlight, 90% incompatible with .NetCF. – yms Nov 29 '11 at 21:35
  • 6
    I started with Webforms and once I discovered MVC I switched to that. I don't know how anyone could defend webforms. Page lifecycle and one form for the entire page? Are you kidding me? Yahoo sitebuilder was probably the intended customer for it but even they didn't want that junk. – The Muffin Man Apr 03 '13 at 21:32
  • Never choose webforms over mvc. You will spend twice as much time in order to fix webforms shortages, then to create a proper mvc page. – John Nov 10 '14 at 13:59
  • 1
    WebForms is not going to be part of ASP.NET Core 1.0 moving forward. It's MVC all the way now. [Source 1](https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/), [Source 2](http://stephenwalther.com/archive/2015/02/24/top-10-changes-in-asp-net-5-and-mvc-6) – CokoBWare May 31 '16 at 19:49
  • @CokoBWare - that's great. This answer is 5 years old. Even still, WebForms isn't going anywhere. Just as people still support VB6 applications, legacy WebForms sites will live on. – Tyanna Jun 01 '16 at 02:05
  • 1
    @Tyanna yes, I am aware of that. But there are people that are still new to ASP.NET MVC who might come into older MVC versions that may not realize that WebForms in the new ASP.NET Core ecosystem effectively dead, and there is no plan to transition any WebForms code to the new hotness. WebForms will live on as legacy, just like ASP Classic lives on as legacy. – CokoBWare Jun 10 '16 at 18:31
  • Anybody choosing webforms for new projects in 2017 is drastically limiting their options and their talent pool. Web-centric developers despise webforms. It's mere presence in DNN is a constant source of pain at my current job. We just had a problem in FF 52 where webforms decided it didn't like Firefox's version of parseInt and replaces it with its own version that THROWS FREAKING ERRORS rather than returning NaN or numbers when given non-strings. And since this process was asynchronous our short term solution required littering our codebase with `window.parseInt = Number.parseInt`. Not cool. – Erik Reppen May 05 '17 at 15:11
  • As someone mentioned above if most of what your applicaiton does is CRUD then webforms would take less time to develop with all existing control libraries and not having to care much about client-side coding, markup and maintaining state because webforms take care of this for you. But if you need something custom outside CRUD and public-facing then you may run into problems getting the exact behavior you need and with performance. – axk Jun 21 '18 at 18:25
  • Also if you have an existing webforms app and then need a new sister app that will have similar functionality doing it with MVC may be a very bad idea becasue then when you're asked to replicate something from the webforms site on the MVC site it's a complete UI re-write and a pain to maintain both then. – axk Jun 21 '18 at 18:29
  • If moving away from webforms I would consider switching directly to a client-side framework like Angular bypassing MVC. With MVC you get a mix of client-side and server side code, e.g. you may need to render the same markup on the server side and modify it on the client side later, which is inconvinient and makes things complicated IMO. – axk Jun 21 '18 at 18:34
81

I emailed Scott Guthrie, an MVC expert at Microsoft. And probably the most qualified man to answer this question. He was kind enough to reply:

"Different customers look for different programming approaches, and a lot love WebForms and think it is great. Others love MVC and think it is great. That is why we are investing in both. "

So, to me this says that its not a technical issue. Its more of a "soft issue", if you will. One of personal preference. This is in line what several of you have said.

Thanks for all the answers.

P.Brian.Mackey
  • 11,123
  • 8
  • 48
  • 87
  • 14
    Scott Guthrie invented the MVC framework for ASP.NET while on a flight back from London to Seattle in 2006/7. Come to think of it, he pretty much invented .NET too (http://en.wikipedia.org/wiki/Scott_Guthrie). Calling him an "expert" is an enormous understatement ;-) – Jamie Howarth Aug 15 '12 at 18:09
  • 29
    That's a nice political answer from Scott Guthrie. If he himself were investing his own Web application you'd see an MVC project and for anything that couldn't be done in MVC, Silverlight would be the fallback. Don't take this as a comment negative towards WebForms, I think WebForms are great for smaller-scoped internal applications that can benefit from 3rd party components such as those created by Telerik. I'm glad Microsoft is moving forward with both technologies. – Sean Chase Sep 23 '12 at 16:47
  • 10
    "Scott Guthrie invented the MVC framework for ASP.NET while on a flight" I think that really trivializes MVC. I don't know Scott Guthrie, but I'm willing to bet he had been peculating how MVC might be implemented in ASP.NET for a while, and used that long flight to implement a bare bones prototype as a proof of concept. – John MacIntyre Jan 17 '13 at 00:37
  • 6
    "That is why we are investing in both." And when we see that web forms starts to decline, we will mercilessly drop it because investing in an ultimately dead product is not in our best business interest. – Quandary May 29 '13 at 07:22
  • Until it is no longer taught in schools, for many years, it will always be applicable in the business world. Colleges and high schools continue to offer intro and advanced courses in vb.net. Its NOT going anywhere!!! – htm11h Jun 27 '17 at 14:47
46

This is a stale question with a lot of answers but none had the answer I would have expected to be listed.

The short answer is:

  • Use ASP.NET MVC if you intend to properly build a web application with modern programming conventions and industry embraced patterns for the ASP.NET platform. On the down side you will be expected to know how HTML and client-side resources (Javascript, CSS) work as well as ramp up on the MVC programming mindset which has a steep learning curve but reaches a sudden end once grasped.
  • Use ASP.NET Web Forms if you're using or want to use a GUI-centric, RAD (Rapid Application Development), drag-and-drop approach to prototyping something very quickly, i.e. push-button / data grid behavior wired up within 15 minutes, and the solution is not intended to be something supported by developers. Or, Use ASP.NET Web Forms if you have a background in GUI or Windows Forms development and you desire to transfer your knowledge to the Web.

But to look at this properly, you have to understand the history of each.

ASP.NET Web Forms was Microsoft's answer to those who had been building dynamic web applications using Visual Basic 6 ActiveX controls, VB6 DLLs on the server, and ASP Classic. At the time, web development using these Microsoft tools was a real mess. Along with the entirety of the .NET Framework which was the output of Microsoft essentially going back to the drawing board on how to do productive business programming on the Windows stack, ASP.NET Web Forms was, in its day, amazing and beautiful.

The whole approach was to give developers the best of both worlds of something very similar to Windows application development, but with the power of internet services. The idea was that, just as with a VB6/WinForms "Form" (a window) likewise a web page is a form (just like a window, see), and on that form you could drag-and-drop labels, textboxes, data grids, buttons, and other things that VB/WinForms GUI developers were accustomed to.

To make a button do something, after dragging-and-dropping it you just double-click it in the designer and boom you're in the code editor, telling the form what to do when that "click" event happens. This was exactly how Windows GUI developers created software using GUI tooling of VB6 and competing tools, except now the code is executing on the server! Wow!

This was 2002 technology. Amazing and beautiful in its time as an answer to internet-enabled GUI solutions for RAD development, it brought a sense of power to a messy world of software developers that had business objectives that they needed to accomplish.

Unfortunately, this programming model emphasizes so much the metaphor of Windows GUI programming that it carries with it the burden of its necessary implementation details, all the encumbering baggage necessary to accommodate the event life cycles and the tucking away the ugly details of the simple HTML and script that these drag-and-drop components and controls would output. And at the end of the day, developers supporting real applications inevitably had to dig deep into these components or write their own, and consequently they would fight battles with this infrastructure, battles which would leave behind piles upon piles of cruft, pulled hair, and tears.

Back up. Wash your hands. Let's look at the business problem again. What are our business objectives?

We need to build and manage web applications. Our constraints are that we have the World Wide Web, which sits on HTTP, HTML, Javascript, and CSS, and on the server we have business rules, databases, and a small handful of great programming languages (e.g. C#). Do we really need this Windows GUI metaphor to drive our development methodology? Why can't we just focus on the application problems and do away with the GUI metaphors?

This is where ASP.NET MVC comes in. It started out by a rebellion of developers who called themselves "Alt.Net" who wanted to get back to proper and pure software development principles. No more muss and fuss, just focus on business objectives and software best practices.

What this really translates to in this case is:

  1. Separation of concerns. For example, a data component doesn't need to know how its data is going to be rendered, nor should view markup be encumbered with database connection configuration details, and in this way a developer can focus in on his area of concern when editing and testing code.
  2. Exposure and full support for exposure to the nitty gritty of HTML and related resources. In Web Forms, HTML is tucked away, developers are discouraged from fussing with that. In ASP.NET MVC, developers are rather encouraged to manage those details; in fact it's a necessity. The advantage here is that the developer can re-learn to appreciate the clean semantics of HTML, CSS, and script, and work with it rather than against it.
  3. Testability of business objects. Controllers and models are much better suited for programmatic unit testing, so that implementations can be validated to meet business objectives, and changes can be verified that they will not break. With Web Forms it was difficult to test as components were not designed to be tested individually and the entire development output revolved around page forms and their event lifecycles with the muck of business logic and presentation logic deeply intertwined.

Note that HTML is already a very high-level markup language, as is Javascript a high-level programming language. The whole story would have been different if we were dealing with Assembly language and C.

Expanding upon #2, then, another objective of ASP.NET MVC is to enable developers to organize the front-end details of the 'view' portion of their solutions and take advantage of the rich foundation that the rest of the industry has built upon the front-end client platform.

You will find that ASP.NET MVC developers feel at home utilizing rich Javascript libraries and client-side templating techniques without fighting with the server-side architecture. This was not originally the case with ASP.NET Web Forms, because Web Forms doesn't want you to look at the HTML or script at all, except if you really have to, in which case, beware, it is not for the faint of heart.

mezoid
  • 151
  • 6
stimpy77
  • 170
  • 3
  • 10
  • This is a good answer, but #1 and #2 are wrong (WF does not require a component to know where its data comes from, it is an option and you have always added HTML to your ASPX files to support the asp tags you are rendering. You have never needed to dig deep and fight the controls unless you were trying to access an ASP feature not intended for developer interaction. The big points are testability and design pattern.) – Trisped May 13 '16 at 23:28
41

I am a complete and total convert to ASP.NET MVC and have not looked back, that said I do still have to maintain several very large WebForms apps. Here's my take on it:

WebForms
Use these when you have some serious heavy lifting to do with grids. The grid controls are really very nice when you have a simple dataset that fits nicely in a tabular format and you want to provide a simple way for users to update records. Yes, I know that MVC 4 has a really snazzy Ajax list-type thing that you can use which works great but, in our business we often need to get something running yesterday and good old-fashioned grids work great and users are happy to be able to tab across a grid with glee. For me that's really the best thing about WebForms for me; but, as Ryan pointed out WebForms can be a big time mess because you're playing both sides of the fence from a nifty code-behind file. It can be both a rose and a thorn at the same time to keep all of your controller-type stuff intermixed with your view(s).

MVC
Use this when you really want to roll your own and you have the opportunity to start an application from scratch. Having a clearly defined MVC application is a bit more work to get started with but its benefits in maintainability outweigh the initial setup cost. If you want to do interesting Ajax interactions, prefer to write your model with code, like clean url's and routes, and be able to control the entire flow of your app then this is definitely the way to go. It takes some getting used to at first but I think it's the better option for greenfield apps.

In conclusion, for me, it comes down to grids and !grids. :)

Community
  • 1
Nodey The Node Guy
  • 2,054
  • 2
  • 17
  • 22
  • +1 for the nice picture delivered with "playing both sides of the fence from a nifty code-behind file". – Marcel Feb 07 '13 at 09:40
  • Very helpful this one. I'm doing a very heavy grid based app and I've ruled out silverlight, xbap and it was down to a show down between these two. – frostymarvelous May 08 '16 at 10:43
15

My experience:

  • Wrote CakePHP projects for one year.
  • Completed a medium sized Webforms project over six months.
  • Worked on a Windows Forms project for three years.

After that experience, I tried writing another app using webforms, and got frustrated after struggling for about a day with how webforms attempts to shield the developer from the reality that they're developing an application which uses html, javascript and css.

I then tried MVC out, and having more direct control over the output (and some experience with the MVC paradigm from CakePHP) I was able to complete that simple app exactly the way I wanted it in about 1/2 a day.

The availability of powerful UI frameworks like jQuery very much eliminates the appeal of giving up direct control of the output in favor of using often bulky pre-built UI components.

mootinator
  • 1,280
  • 10
  • 18
  • -1: What kind of app can anyone realistically develop in a half day? – Jim G. Jun 16 '12 at 00:53
  • 2
    @JimG - Uhh, anything which involves a person entering records without interesting associations into a database, and having that person or someone else read/print them at some other point can be basically scaffolded using an MVC framework. Granted, that isn't most apps, but it's a heck of a lot more than you can do with Forms. I guess your -1 proves my point. – mootinator Jun 17 '12 at 16:46
  • So let's get down to brass tacks. You can develop an entire (shippable) app between your morning coffee and lunch time? No way, dude. Perhaps one day, but not a half day. – Jim G. Jun 17 '12 at 17:12
  • 1
    That's 1/4 of a day. – mootinator Jun 18 '12 at 00:12
  • 1
    But if the requirements amount to "I need an app with two roles, one to record some information, the other to look at it, and I don't really care what it looks like." Then, yes, that's quite doable. – mootinator Jun 18 '12 at 00:19
  • 3
    im sorry, but developing a webforms app to enter data and view data is so simple, that it can be done in a few hours. creating the structure of an MVC app, Controllers, Views and Actions, would take the same amount of time, but will not get you to a finished product. – Rafael Herscovici Jun 20 '12 at 15:41
  • 2
    @Dementic Usually for a simple MVC app one builds models, then scaffolds controllers and views and/or generates scaffolded controllers/views. Nothing really time-consuming there. – mootinator Jun 20 '12 at 18:32
8

I prefer webforms because my background is windows development.

Speed of developmnt is a key issue, and I can easily pass a problem to someone in india to fix overnight with forms, also, if I have a speed issue on a page, a really good book about asp.net speed is handy ( Rick Kiessig is the man ).

webforms is for ex windows people mvc is for web people

but, in the modern world, where Rick has written an awesome book, with servers increasing in speed daily and cheap coders in India, well, webforms has the edge

jason palmer
  • 21
  • 1
  • 1
7

My 2 cents is to always use ASP.NET MVC for new projects if you have the option. In my opinion, webforms is not a good way to develop web apps, period.

I think abstracting away basic REST is bad, the entire postback model is bad, the way html/css is handed with a reliance on the GUI editor is bad, the emphasis on stuff like wizards and GUIs to set stuff up is bad, the URLs are bad.

scottschulthess
  • 137
  • 1
  • 5
  • could you explain in more details why you think so? – gnat Jan 16 '13 at 07:49
  • i think abstracting away basic REST is back, the entire postback model is back, the way html/css is handed with a reliance on the GUI editor is bad, the emphasis on stuff like wizards and GUIs to set stuff up is bad, the URLs are bad, etc and so on – scottschulthess Jan 16 '13 at 14:16
6

I have read all the answers and feels my personal experience would add something to the answers above.

3-4 years back, I developed 2-3 website projects using Webforms. Around that time, MVC wasn't around or i didn't heard of it. The development was naturally(I was coming from Win-forms development with no prior web development experience) fast for me, since i need not to learn HTML in details and web-controls helped a lot (a hell lot, it made life easier).

Now, after all that time, i wasn't working any web project until recently and merely building some windows application using WPF.

Few days back I had an idea for a website and thought of developing it : this time around in MVC (since its talked about everywhere, besides i needed to learn either, so i choose MVC). The project is still in development phase, since i am still learning and building together.

So, the Key differences i find b/w the two are following :-

  • For someone coming from windows development, Web forms will always be favorable. Asp.net learning curve for a windows developer is bit steep

  • For someone coming from web development in some other technology, MVC will be favoured since it mocks the latest of them all.

  • Development is easier and cleaner in MVC if you are equipped with good knowledge of HTML and CSS

  • Deployment is still an issue. In web forms one just needed to do copy and paste. But, this requires some things to be done.

In short, both of them will stay here for a while.

Pankaj Upadhyay
  • 5,060
  • 11
  • 44
  • 60
6

I've not seen this consideration put forward amongst the existing 15 answers to this thread yet, but I think it's worth considering.

From my experience Web Forms is more similar to Win Forms and WPF than MVC is. Given this, I think one might consider choosing Web Forms when the team has most experience in that kind of tech, or when the Web Forms project will deliver an interface on to the same data set as an existing (or concurrently developed) Win Forms or WPF project. Doing so allows developers to cross between projects more easily, since application logic may be quite similar between the two.

As other answers have pointed out, development on the MVC framework is more similar to web development in Ruby, PHP, Python etc than its Microsoft counterparts; so naturally the choice of MVC can be influenced by the teams experience in those areas, along with the factors submitted in other answers.

Andy Hunt
  • 5,996
  • 1
  • 33
  • 56
  • +1 Certainly a reasonable argument for Webforms. My fear is that teams follow this mindset to avoid learning new things. MVC is filled with many patterns that may be unfamiliar to a team. Learning these types of patterns and implementing them leads to better adherence to SOLID principles which translates to better overall maintainability. These proven techniques are the also the real key to re-useability. – P.Brian.Mackey May 02 '13 at 13:17
3

Our reason for not going to MVC a few years ago was it was an immature technology from Microsoft. Over the past few years we are now on a more mature version (4) and MS seems to have worked out where they are going with this. However, we are still reluctant on developing major LOB apps using MVC as the features we want to use in version 4 require a windows 2012 server (re web sockets via IIS8). I reckon in 1 more year we will be more accepting of MVC as hopefully more third party controls will be available, the technology will have settled, and we will have the infrastructure to support it.

Steve
  • 1
  • 1
2

The only reason why I would choose the WebForms instead of MVC is because you have much more 3rd party UI controls for WebForms than MVC. I choose MVC because I worked too much with WebForms and I want to work with something fresh / new, but still from MS shop :)

Basically, nothing prevents you to turn off the viewstate in WebForms and use ViewModels and if/for loops instead of model binding and server side controls.

Is this WebForms or MVC code:

<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>

The only limitation I found in WebForms is that if you use Dependency Injection / Inversion of Control, you can't have constructor injection since WebForms pages must have parameterless constructor, so you have to use property injection. Is this really such a big deal?

šljaker
  • 476
  • 3
  • 10
2

This decision depends on your preferences, on your requierements or even on your knowledge and experience.

The time for training learning MVC or time to get a delivery. All this things matter to choose one or other aproach.

Is not that one is better than another, simply both aproach or frameworks have pros and cons.

Personaly I favor MVC 3, I recommend you to try an get your own experience, but I need to say that program in MVC is a clean, fun, flexible, extendible, secure and structured way.

Regards,

pacoespinoza
  • 141
  • 4
1

ASP.NET MVC is really an answer to Ruby, and the new, trendy, and (IMO) better way of decoupling the browser(client) from the server as much as possible.

ASP.NET Webforms gives you a lot of control over the client from the server side, with direct access to pretty much everything. Essentially your view and controller are one in the same, which gives you a lot of power, and most times a lot of mess.

ASP.NET MVC separates the view and controller by detaching the tight coupling of a .aspx file and the .aspx.cs file which accompanies them in webforms.

Essentially, the difference is having your much more (typically all) of the processing to display data to the view file, and leaving the business logic and the rest in the controller, keeping them both cleaner by convention, but also with less access to each other than webforms allows.

Ryan Hayes
  • 20,139
  • 4
  • 68
  • 116
  • So WHEN should webforms be favored over MVC? This does not answer the original posters question. – Steven Striga Jul 22 '11 at 17:35
  • @WeekendWarrior - It does, when you want more server-side access to the client, choose webforms. If you want more decoupling of the client/server in your code, choose MVC. At the end of the day, they both do the exact same thing. Reroute filters do the same thing as the MVC urls and you can move webforms code behind to a separate middle tier to decouple it more. http://weblogs.asp.net/scottgu/archive/2010/01/24/about-technical-debates-both-in-general-and-regarding-asp-net-web-forms-and-asp-net-mvc-in-particular.aspx – Ryan Hayes Jul 22 '11 at 17:43
  • Regarding your third point, that business logic ends up in the .aspx.cs file -- I think this is the fault of developers. It's not /supposed/ to be there. In Webforms, the .aspx is the "view", the .aspx.cs is the "controller" equivalent, intended to process the code that directly relates only to the UI by polling a business layer or coarse grained business facade layer. The fact that people put business logic in the .aspx.cs is just poor programming. They could also put business logic right in the view in MVC! MVC doesn't force separation of these things. – James Dec 01 '15 at 08:52
  • Essentially he is more right then other answers posted here. ASP.net is the basic idea behind a modular web technology family as created by Microsoft. ASP.net MVC module might be a temporaly hype but for sure its not the last, it all starts with ASP.net, so when to choose ASP.net, if you dont think that MVC is not your thing, maybe your more into something else OWIN or ... , something more advanced, or made your own framework for your tasks. You might not even need ASP.MVC and skip it and go Owin or Katana, but untill your there use asp.net – Peter Oct 24 '16 at 14:31
1

In my opinion, they are related enough and have roughly the same capabilities that it should come down to preference.

A great WebForms developer can produce a product equally powerful as a great MVC developer. But the great WebForms developer trying to force himself/herself to adopt MVC is going to come up short. Same goes for a great MVC developer giving WebForms a shot.

They are not completely separate entities, and as long as Microsoft continues supporting both, I believe you will continue see a mixed group of exceptional developers for each.

0

This is all about personal choice, assuming we are all proficient with the technology we use. I have been using the WebForms design approach for many years, and I must say that the only downside is that due to it's simplistic approach, many people do not take their time to unearth it's vast capabilities.

I recently used MVC to complete a project, and while I quite like the design approach to application development (which gives you more control, clean urls, SOC, etc), there really isn't much it provides, that WebForms can't. In fact, the emergence of jQuery and it's workings with WebForms (as well as MVC) has made these arguments less of an issue. And when people talk about separation of concerns as an advantage MVC has over MVP, I ask them how much they know about Object Oriented programming and how much they put into use the principle of abstraction and polymorphism.

I am currently comfortable using both technologies and I pick and choose based on the situation. Frankly speaking, it is up to you, but the truth remains that not everyone takes their time to learn in depth what a particular technology is capable of.

David Grant
  • 1
  • 1
  • Ditto on the vast capabilities of webforms. Most folks are seeing the training wheels of webforms and comparing this with MVC. – TheLegendaryCopyCoder Aug 04 '16 at 14:33
  • There is little sense in learning an abstraction on top of HTML and Javascript in this day and age (even in 2013). It'll do you no good for your future opportunities. HTML and Javascript is just fine the way it is. Fighting it is a losing battle. – user441521 Aug 10 '17 at 19:18
0

When faced with a programming problem I often look to the web for answers. Webforms has tons of information/components on doing just about anything. In MVC due to fewer sources online and the layers of abstractions needed to make something work has put a limit in things that I could once do. MVC total kills my productivity as a developer while with Webforms it ain't. So for now I'm sticking to webforms until MVC has matured enough to replace it.

Sonny
  • 1
  • 1
0

Well, WebForms have more learning resources available (simply due to the fact that it's older) and thus new programmers that aren't "in the know" will be more likely to find information regarding this older technology as opposed to the newer stuff like MVC.

Senior/experienced programmers are older and will be more proficient in the older technology due to the fact that they've programmed in it longer than they have in the newer one.

Unless you can spend the money and effort to get your guys as proficient in MVC as they are in WebForms applications, you're undoubtedly going to try and hold off upgrading to the new platform for as long as possible.

So it presents several logistical problems: Do the benefits of MVC outweigh the cost in terms of lesser quality and deployment time? If I have a site written entirely in WebForms, would it be worth the effort and money to integrate MVC into it?

As stated by a previous commenter, MVC also prevents you from achieving the same level of interface with the controller as you would be able to with WebForms. While I'm all for the "Keep the user from stuffing things up/learning" side of things, it can still be unreasonably troublesome for teams to deploy/implement a program that fanatically sticks to that paradigm for everything they write.

WynandB
  • 101
  • 4
-1

Let's imagine there is only MVC framework in .NET platform and someone says:

"we need to evolve a new framework specific for enterprise solutions, based on asp.net, that will focus on rapid business applications development and abstract html as an pre-designed presentation layer."

WebForms could be the outcome.

When I worked with WebForms I saw data controls, state management, modularity, composition ... not html. Html wasn't the case or focus.

Panos Roditakis
  • 29
  • 3