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?
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.
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?
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.
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.
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:
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:
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.
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. :)
My experience:
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.
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
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.
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.
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.
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.
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,
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?
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.
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.
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.
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.
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.
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.
;at my webpage (If you're just beginning with Razor you'll get the joke).