It seems to me that, for structured development with both depth and breadth of capability, ASP.NET MVC and Silverlight have the potential to make a nice powerful framework with superior UI granularity and reduced AJAX exposure. Have any of you tried building such a stack with future durability in mind?
ASP.NET MVC and silverlight?
In some ways, it is an either-or choice - your data is displayed either in html/css/js generated by ASP.NET, or in Silverlight. Why mix them? I'm sure that ASP.NET MVC is a good way to deliver Silverlight, but that doesn't necessarily make it part of the same UI.
It's generally about reach vs. richness. A web UI with no Silverlight or Flash can reach more users, but one with Silverlight can have a richer UI. Silverlight is good fun to code in, and I have seen some wonderful apps using Silverlight's streaming video features, but if e.g. you are doing data entry and display, and you don't need the richness of Silverlight, then why not keep the reach and stay in Asp.Net?
If you are going to do the UI in silverlight it makes sense to do all of it in Silverlight. I have had good experiences with all the ViewModel-view-controller page flow happening inside the Silverlight app, rather than transitioning to another html page and loading a different silverlight app. It's faster and you can do fancy transition or fade-in effects in Silverlight's XAML markup.
Why is "reduced AJAX exposure" a desirable goal? Sites like e.g. Stackoverflow here use AJAX techniques to very good effect.
Stephen Walther's talk at MIX09 shows four pillars of ASP.Net as it currently stands - Forms, MVC, AJAX and Dynamic data. A lot of people are Seeing it as "moving from forms to MVC" but there are other approaches also being developed in the mix.
I've built a little test app with SL and MVC. It didn't work that well but I don't think I was doing right. I've tried using SL in views but its slow to switch pages since its loading new SL instances all the time. I've tried a single SL app which meant it contained all the control code as well but that relegates the server to data access which only needs some WCF/Web service code no need for MVC there.
It may work better if we dispense with the idea of there being many view pages. In my next iteration I shall be using controllers to respond with XML or JSON directly to requests from a Silverlight app which contains the views. However this approach would still leave some questions unanswered, for example, how does the controller get to have a say in what view is actually displayed?
To be honest, I'm getting the feeling that SL to ASP.NET-MVC are yet shaping up as a good match. Some web apps may benefit from some SL elements (charting for example) yet the app remain firmly in HTML. On the other hand, an app whose UI is purely in SL (whilst internally using some similar View/Controller concept) doesn't really need MVC on the server-side.
Its early days, it will take while for us early adopters to see what really works and what doesn't. There being a beta for version 3 with more coming from MS in the way SL can access serverside data may change things further.
I asked a similar question here: Does Silverlight 3 Change the MVC vs. Silverlight question. This was in response to SL2 vs. MVC where folks all agreed that they were complimentary technologies. I'm still not convinced. My experience has been similar to AnthonyWJones. Per the previous posts, I tried to mingle them without a lot of success. Could be my own ignorance, though. Right now I'm building a Silverlight only application using SL3 beta. I seem to be a lot closer to my intended effect. That being, an application with a few database features. So it didn't make sense to build a completely stand alone app (since the data is central), but I really wanted some Silverlight goodness to render the end result and allow the user to interact.
So where in the hell am I going with all of this? Based on my experience, this still seems like a YMMV type question. It really depends on what you're trying to build. Since I'm light on database, heavy on interaction, I'm biting the bullet with Silverlight 3 and .NET RIA Services for the little database stuff. If I were writing Stackoverflow, I'd probably do ASP.NET MVC and AJAX.
We are currently using ASP.NET MVC as an alternative to WCF to expose data to Silverlight where our Silverlight app makes RESTFUL calls to urls in our Mvc application and the controller returns a JsonResult which works well for us. It's by no means necessarily the text book way but we found this way the two technologies compliment each other. Now if we ever need an HTML implementation we've already done the Model-Controller work which can be re-used.
Related
I have read just about every question/answers about webforms vs MVC. But none has addressed what I am about to ask.
We are a small development team (3 ppl) and we have a legacy application similar to Crystal Reports.
We need to convert this VB6 app to a web based app. Reason? It was written in VB6 and support for VB6 will be phased out in Windows 8. This application is / will be similar to Crystal Reports / Google Docs where thousands of users will use the web app to generate complex reports from a large database. Charts and graphs will be generated dynamically based on the data queried. All reports can then be exported to PDF and other supported document file types. Possible feature is creating Word documents with this data or at least annotating the PDF reports. Document/Content Management back end also required for storage and searching.
OK - so clearly its a rather complicated web application with loads of database access/queries. The front end will also need to be rather spick (although gridviews not compulsory).
Constraints:
1. Time to market is relatively short (6months to 1 year)
Technology should last or be available for the next 10-20 years - We can't work on this application forever, having to constantly updating and re-writing it every time new technology supersedes older technology. HTML will last beyond this time, but will ASP.NET?
User end performance needs to be relatively quick. it doesn't have to be blistering quick; but it shouldn't lag so much (more than 2 seconds for response) that users begin to complain. (ie ViewState not a prob if it doesn't exceed 100Kb).
Please answer my questions:
So my question to you is: do we go with Webforms or MVC?
MVC sounds attractive but MVC is STATELESS. Do you think this application will need to keep state or can I do without it? Or is it possible to implement state in MVC (confused)?
Some users are in govt departments and have have laptops that a clamped down for security reasons (by their IT Admin) - so Javascript, for a significant number of users will be TURNED OFF. This means JQuery may not be possible technology. Is there some way to accommodate for Javascript and non Javascript browsers?
Thanks in advance.
Sam
Use Web Forms.
Here's why:
1 - Faster development time (rapid application development) - as stated in your time constraint
2 - For complex charts/reports/grids, you'd have to roll your own with ASP.NET MVC (or use a helper someone else has created). But with Web Forms you have a wealth of server controls (and products like Telerik).
So do answer your questions:
Web Forms - see above.
We can't answer that - we don't know how exactly your application will operate. MVC is not stateless per-se, it is stateless in that it doesn't use ViewState. But you can still use things like Session.
JavaScript is client-side, and has no bearing on Web Forms vs MVC. You'll have to cater for scenarios with no JavaScript (minimize AJAX work, effects, etc).
You've mentioned "speed needs to be quick". Well if ViewState is a problem, then turn it off! It annoys me people who say "I hate ViewState, it makes pages slow", when you can simply turn it off at the control or page level.
BTW - i am by no means a Web Forms advocate - i actually prefer ASP.NET MVC. But from what i've read in your question, i would go with Web Forms.
This is completely subjective; use which ever one you want. I personally prefer MVC, but use which ever you want.
HTTP is stateless, no matter what the client or server are. That said, all web frameworks have tricks to make it appear stateful. MVC is not an exception here. It just doesn't use the same trick that ASP.NET Webforms does.
Yes. Detect if they have Javascript enabled, and be sure to provide alternate, server-only ways to do the same functionality.
MVC
I think both are viable choices, but I would personally go with MVC, considering the MVC 3 release candidate is out now, and has some awesome new features. I would go with MVC because it will be extremely maintainable and scaleable once the project is complete. This sounds like it would be very helpful for you since your project does appear to be quite complex. Conversely, however, it would take longer (at least from what I have experienced and read) using MVC over WebForms, so, if you feel that your team really needs to meet that deadline you mentioned, perhaps go with WebForms.
If you wish to proceed with MVC, its stateless nature should pose no problems to your project, at least, not that I know of.
Although the fact that JS may be turned off is slightly irritating to work with, WF and MVC will have to deal with issue similarly, and should have no impact on your final decision.
go with webforms, you can always sub some of the work out to india where they have been using webforms for years, if you get speed problems then let them tackle em by playing with viewstate on component levels
though really
ultra fast asp.net by Rick Kiessig solves 99% of all speed issues with webforms, if you have that book then webforms is a no brainer
mvc was a microsoft fork because a lot of web people could not optimise the viewstate
now you can turn off viewstate per page or per component, or just email india with code and say 'speed this up, someway'.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I find myself on the edge of trying out ASP.NET MVC but there is still "something" holding me back. Are you still waiting to try it, and if so, why? If you finally decided to use it, what helped you get over your hesitation?
I'm not worried about it from a technical point of view; I know the pros and cons of web forms vs ASP.NET MVC. My concerns are more on the practical side.
Will Microsoft continue to support ASP.NET MVC if they don't reach some critical threshold of developers/customers using it?
Are customers willing to try ASP.NET MVC? Have you had to convince a customer to use it? How did that go?
Are there major sites using ASP.NET MVC (besides SO)? Could you provide links if you have them?
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
If you have any other concerns preventing you from using ASP.NET MVC, what are they?
If you had concerns but felt they were addressed and now use ASP.NET MVC, could you list them as well?
Will Microsoft continue to support ASP.NET MVC if they don't reach some critical threshold of developers/customers using it?
They will for sure.
Are customers willing to try ASP.NET MVC? Have you had to convince a customer to use it? How did that go?
Customers care about high quality products and price. Just convince them that Mvc will help to raise quality and lower price. Shouldn't be hard.
Are there major sites using ASP.NET MVC (besides SO)? Could you provide links if you have them?
Isn't it enough with SO? :)
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
I did try and didn't regret it at all. It kills me being forced to work on web forms project again.
Go for it!
I believe ASP.NET MVC has reached that critical threshold, as evident by VS 2010 tooling, ASP.NET, MS employee blog and the extensive effort Microsoft put into the framework thus far. I don't see this framework perishing in the next decade (or two).
By customers, I assume you mean people that I build websites for? The only issue I find with ASP.NET is the hosting solutions. However, this issue is becoming moot as more affordable hosting solutions are found. But usually, if I believe in the technology and that it will work for my customer, my customer trusts me and agrees on it. The customer is also usually comforted by the fact that ASP.NET-MVC is a Microsoft product. Having a big company behind a technology is always a nice thing to have, since you can rest assured it will be supported for quite awhile with frequent updates.
ASP.NET MVC is a relatively new framework, and slow adoption of new technology is expected. But this is what I found: http://weblogs.asp.net/mikebosch/archive/2008/05/05/gallery-of-live-asp-net-mvc-sites.aspx . I think you'll see a big influx of websites using ASP.NET-MVC this year when VS 2010/.NET 4 are released with built-in support for ASP.NET MVC.
I never enjoyed developing with C#/ASP.NET more than when I started using ASP.NET-MVC. To a certain extent, ASP.NET-MVC forces you to write good code more so than WebForms due to ASP.NET-MVC inherit separation of concerns and easy customization. And the ability to control HTML output is essential, a feature that was difficult with ASP.NET-WebForms (pre 4.0).
I use MVC and hate it, especially, the front end, web form are far more better in the front end... With loads of javacript on the page, that means it is hard to maintain and take a longer time to develop and debug..
To do a very complicated page, the flexibility of MVC is limited, you will end up with using a lot of javascript control, and you know what? Different controls use different version of jquery, and they have conflict..
It is actually the javascript, and lack of UI flexibility that pulls me off, especially you are NOT working on your code
and we have more issues of browser compatability, with the new browsers coming, you are going to shoot yourself with MVC
MVC front end is very fast if your web site is not too big.. The backend of MVC is very good, it is the front end that blows it over
Why not? The rest of my team doesn't want to.
I have not yet actually tried coding up some ASP.Net MVC(looked at a few examples though) but the main thing holding us back from using it is that all of our code is currently written using Webforms.
Regarding Microsoft support ASP.Net. First Scott Guthrie, the VP of Development at MS is behind it, so that's one feather in its cap. Second its open source now so even if for some strange reason MS decides not to support it going forward you can still tweak it on your own if you need to. In addtion the MVC pattern is somethign that more and more web development platforms are using. It is a great pattern for web development and as a result I can't think of any reason MS wouldn't continue to support it.
If by customers you mean end users, honestly they shouldn't care how you implement the site. If by customers you mean consulting clients, if you can develop faster and they have the servers that can host it, I would think they would be open to it. On top of that youre MVC sites should use less bandwidth than a typical Web Forms web site (IMHO) mainly because there is a lot of additional stuff put into a Web Forms page (for example extra attributes in the HTML htat are tailored for web forms, ViewState) so that should be seen as a positive by them. Now if by customers you mean people integrating with you, then its also a plus since MVC makes it very easy to implement REST based web services (not that WFC doesn't but MVC works very nicely as well).
Hmm major sites using MVC, so far I've found a list here I also know of a number of apps at different companies where large scale MVC apps are in development. I wish I could give more detail, but unfortuantely I can't at the moment.
When I first started out with ASP.Net MVC I thought I was going to hate it. I wasn't a huge fan of Web Forms either, but MVC just felt like a step back to ASP development back before .Net came out. Then I started really getting into it and really finding the pattern is clean, concise, extensible, maintainable, and easy to pick up. Honestly I don't want to ever go back to Web Forms, and anytime I find myself doing a .Net web app I make a point of making it an MVC project.
You need to choose what's more appropriate to your product. Webforms has a few things to recommend it over mvc in some situations.
The big one is a developer working on in-house tools at small to medium shops. In these circumstances:
Large viewstates are not likely to be a problem, because your users typically have 100Mbit upload to your web server rather than a measly 128Kbit or less.
Javascript is likley to be supported by everyone
Development time matters more than widespread cross-browser compatibility or even nice design.
You're likely stuck working with inherited devs who used to do desktop/forms style development, or have a lot of churn among junior devs who don't really know web development.
All of those things together mean that webforms is still a very good fit. And let's be honest: a lot more programmers work at these small to medium in-house shops than do public internet work. So webforms isn't going anywhere.
That said, one of the big things coming up among these small shops is likely to be taking their internal tools and making them available offsite for telecommuters. In that situation, you need to start worrying more about WAN performance odd browser issues where MVC might be a better fit.
Dell is hiring masses of ASP.NET MVC developers in Texas and India for major work on many of their websites.
According to The Gu, ASP.NET MVC will have it's own product and development cycle. It is now 100% detached from ASP.NET WebForms and it's not going away.
Did you try ASP.NET MVC and found yourself regretting it? If so, what do you regret?
I do not regret trying out MVC in fact I love it. When I started it out I hated it I kept looking for the code behind file and was unsure at first how to get values out textboxes and stuff without going textbox1.Text;
Now I cringe every time I go back to webforms and wish I could write it in ASP.NET MVC because I just love how your working with html instead of using drag and drop controls that usually make your life alot harder if you got to customize them to much. I love how ASP.NET MVC likes to focus on good code like design patterns such as the Repository pattern and how to do unit test using TDD.
I have not picked up a book yet in MVC where they talked about how to make good code. I am not saying you can't write good code in Webforms but in the books and classes that I seen teach ASP.NET this never seems to be a main focus.
Like for instance I hate the datasource controls I am tutoring some people in WebForms and they love to drag a datasource in and then write their SQL statements in that datasource. Then in the code behind they use these datasorces to insert their records.
So every time they need to make a new SQL query a new datsource is dragged on and made. So now you all your logic is all mixed together. It makes it so much harder to find out whats going on, switch to different things if needed then of course it is limiting.
Something that revolves around the name "controller" can only mean problems.
I tried following the Nerddinner http://www.asp.net/mVC/ tutorial this morning. I'm comfortable in webforms, but nothing in that nerddinner tutorial made sense, just an outdated, hardcoded recipe from mvc1.0 that dosent even compile with the current mvc2.0, probably Wrox made this tutorial, only they can come up with only formating and no content.
I didn't see anything in there that was good; a bunch of hardcoded conventions I didn't need.
I certainly didn't see anything in there that would make me say I'd want to move from webforms, although this seems to be all the propaganda I read.
They put this tutorial based around wizards, on http://www.asp.net/mVC/ main page, while claiming the model is lean, all of it is generated code they don't explain, the default mvc template project has something like 15 references.
This 2 page website managed to be slow to build and to load.
Was 30 minutes in it until I realized my data model didn't match the one from the tutorial and many things that had been generated using the create controller and create view wizards were now failing.
With what I was provided in the rushed tutorial, I wasn't able to recover the project. I'll just pass until I find better documentation.
I'm frustrated recently by all of the choices that Microsoft offers to develop a web form. There is Sharepoint, Infopath without Sharepoint, ASP.NET Web Forms (with different controls for each runtime), ASP.NET without Web Forms, ASP.NET MVC framework, Silverlight, and WCF. Rendering and databinding technologies aside, there are a handful of different ways to pass data to and from the database (DataSets, LINQ, SqlDataControls, and many more) And those are only the ones that I can name in a minute or so - I'm sure I'm missing some very old technologies (did FoxPro ever get a web front end) or very new things in the process of rolling out of Microsoft Labs.
If I want to move away from using ASP.NET Web Forms and DataSets, what's the best way to move right now for data driven forms? What have you worked with that delivered good value for your programming time? I'm tempted to try working with LINQ to Entities and the new MVC framework, but I don't know enough about all these new technologies to choose where the value lies.
It's been said many times before - there is no "what's best". If any of these tools were best, than the rest wouldn't exist. "Data driven forms" is a pretty broad requirements statement.
They all have advantages and disadvantages in other areas, but all of them are capable of "data driven forms". MVC is lower-level forms - you will have to put in all the HTML and form processing yourself, however, it is much closer to dealing directly with HTTP, so lots of people find it much lighter-weight and easier to work with.
Silverlight has drawbacks in that it uses a diminished set of the .Net libraries, and requires the users to install browser plugins.
WCF would provide the data behind your forms, and would be very suitable if you're planning on opening up a public API or consuming the data in other ways.
You may find it beneficial to research each technology for even an hour each, and you would have a better understanding of which might fit your needs.
If you're using ASP.NET (which, when trying to code a regular website, feels a little "shoehorned"), then I thoroughly recommend trying Microsoft's MVC framework. It's a real breath of fresh air!
From a value per working-hour POV, it really depends on what you're doing. I can't say I've tried many web-frameworks, so I may not be the best metric, but using MVC everything fell into place naturally and I'm happy to stick with it for now.
I don't think ASP.Net Forms is something you need to "get away from".
MVC certainly has it's usefulness and when appropriate certainly makes a lot of stuff simpler.
But a well designed ASP.Net Forms app can be just as or even more useful in certain situations.
Myself I use MVC for public facing sites and Forms for internal/administrative stuff.
For a data-heavy page, I think web forms is a perfectly adequate solution. MVC introduces separation of layers which may make it harder for you to develop, since it forces you to separate the gathering of the data and routing it.
I'd say MVC is nice for having an interactive web page (Web 2.0-ish) but if you are simply showing a bunch of reports, or making users fill out forms - there's not much for you to take advantage of, IMHO.
As an alternative, try writing less code with built-in controls like Repeaters or DataGrids or even DataSets. Getting down to the core of your data flow allows you to be more productive by writing smarter code - not necessarily by writing less code.
In the end, I've found that I put together my own "framework" that does exactly what I need. I get HTML directly from a custom control. These controls simply format the data being fed by procedure calls to my custom Database access class. And yes, these are all served up with web forms or http handlers (ASHX) and a little bit of jQuery.
So while it's not glamourous, it gets the job done faster and better - by developing code that is fine-tuned to my business, not to some abstract software design pattern.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
I am trying to teach ASP.NET MVC to students (undergrads) that have been studying ASP.NET for the last 8 weeks (I know that doesn't sound like much time, but the class is 4 hours per day, 5 days per week with Labs, Quizzes, Exams, and Wrestles).
I haven't gotten the question yet...but I know it is coming...
When would I use MVC instead of ASP??
I don't have any real experience with ASP MVC and I can't find any sort of clear-cut answer on the web. Arguments such as "...the web is stateless and ASP MVC is a closer match etc etc" do not mean much to them. They are starting to notice that ASP has lots of controls that seem to simplify their markup compared to MVC.
I'm trying to give an honest spin, and any feedback would be much appreciated!
TIA
Statelessness is a good one word to explain as already highlighted by the members.
Apart from this ask the following questions to the students?
If they have to do the following with ASP.NET (no MVC), how easy will it be?
Test your views
Mock Http objects.
Viewstate reduction (by design)(
Substitute lightweight viewengine for .aspx.
Thorough separation of concerns.
Clean HTML
etc. etc..
Now explain asp.net mvc in the above context. There may be more to it.
Atleast I think they will get the point, thought this may not be applicable to all project, but what's the harm if we are only gaining from this.
To me, the MVC approach is a very different paradigm from the ASP Forms API. I think the idea of being "stateless" is a good way to explain a very broad topic in one word actually.
One of the major advantages that I've seen is that the MVC framework gives a lot of control over the design and the output of your page. For small projects, this may not be the best use of it, but for large projects, it scales very well because you can make different architectural choices that (personally) I find to be better, such as the way that the MVC framework separates logic from the view.
Also, if you're designing a site that has a lot of Javascript, the control you gain over output in the MVC framework can be very helpful because you don't have to worry so much about how IDs and other markup may be rendered, like you typically do in the ASP Forms framework.
The MVC framework is really a totally different way to design web sites. Personally, I think it is more beneficial for large projects, but I also started out in web languages where MVC was a more popular design choice to begin with.
That's just my 2 cents.
I always thought the ASP.NET MVC Framework was a bad name since its a Design Pattern.
The question should be :
When would I use ASP.NET MVC Framework over ASP.NET Web forms?
The Developer Experience
a) ASP.NET Web Forms tries to abstract away the stateless nature of HTTP from the developer. The state of GUI Elements, and or data is stored in the Viewstate/Session. Everyone Form does a postback to itself, basically mimicking the behavior of a WinForm event driven design.
b) HTML GUI Elements are further abstracted by Controls which can be re-used, bought from 3rd party vendors. This helps developers glue an HTML app together without to much JavaScript and HTML/HTTP Knowledge. Basically similar to the way you would develop VB / WinForms
c) You can do a good job implementing the MVC/MVP pattern in ASP.NET webforms. Look at the Patterns and Practices Web Client software factory to see how they did it.
d) Developing using WebForms you are generally changing the HTML (View) based on user feedback at the server. Most events (user clicks a button, edits a field) are handled at the server in a continuous postback loop executing whats called the ASP.NET Page Lifecycle.
VS
Browser controlled view (dont know what else to call it). All changes to the HTML based on user input is handled in the browser. You will be manipulating the DOM with Javascript.
Note: I basing this on the fact that ASP.NET MVC is most likely driven by basic HTML + Ajax
How I would personally choose between them (never having used MVC, just reading on it)
1) If I was to build a pure stateless front end using Ajax, Jquery, EXT JS type libraries ASP.NET MVC would seem the better fit. Although you could build this in ASP.NET Webforms it seems pointless since you not taking advantage of the Postback model and Server Controls.
2) If I were asked to build a new basic web application, I would stick with ASP.NET Webforms since i'm already familiar with it and know the whole page lifecylce.
3) If I were asked to build a Web 2.0 (hate that term) to have a next gen User Experience, I would probably go with ASP.NET MVC, and use JQuery / ASP.NET Ajax client controls.
4) Many companies have built up a solid set of WebForm controls to use. It would be costly to rebuild them all in a pure stateless ajaxy way :)
For someone with experience (and pains) in Winforms - the biggest difference is no more Viewstate. The state of controls on the form is kept on the client, in the browser and sent to the server for each request.
If you use Javascript, it is easier to make changes on the browser side, while the server side gets an easy way to look at the form as a whole without having to recreate controls binding.
Beyond all the nice things MVC provides - separation of view/code, testability - this was for me the key point to move to MVC.
Apart from all the other excellent responses already listed. Webforms is an abstraction away from HTML.
When you want a html table of data, you put a "gridview" control on a page - what you end up with is "gridview" html, and quite possibly not exactly what you were after.
The shoe fits 90% of the time, but a lot of the time, especially when things move beyond a basic site that the controls don't fit. Using Webforms often means that you don't have full control over the final output that is rendered to the browser.
You can of course extend, or write your own grid control. But wouldn't you just prefer to write the html you want instead?
It's my experience that has the projects get more complex, and UI's get more complicated that you end up fighting webforms more and more often.
http://www.emadibrahim.com/2008/09/07/deciding-between-aspnet-mvc-and-webforms/
I've read all the marketing speak about how mvc and webforms are complementary etc...
However it seems that all the blogs talk about is mvc and the only news coming out is about mvc.
Is Microsoft going to continue to IMPROVE webforms as a first class citizen or will it just be a supported technology as they move all their real efforts, developers and resources to mvc over time?
Is there any real evidence of any new exciting improvements coming to webforms in the near future?
You could do worse than take a look at Phil Haak's post from November:
The Future of WebForms and ASP.NET MVC
He points out 5 key things anounced under ASP.NET at PDC last year:
Core Infrastructure including scale and performance
Web Forms including issues with Client IDs, ViewState, CSS use, etc
AJAX
Data and Dynamic Data
MVC
Coupled with that, there are things that have been built as part of ASP.NET MVC that have already been released for webforms like the Routing module which is going to be great help in some of my projects, even without using MVC.
On top of those, there are also a number of changes coming in VS2010 that should help web developers using either WebForms or MVC, which would be good.
Bloggers tend to talk about what is shiny and "new", that's the way things go - you're bound to see a lot of words written about it because of that, although MVC is hardly a new design pattern - it goes back at least 30 years.
The same could be said of WPF/Silverlight - are they WinForms/WebForms killers? No. They are alternative offerings, with some benefits over the earlier way of doing things, but also with some differences/drawbacks.
I was at a conference (Remix 08) and Scott Gu said they will definatly be continuing to support both methods and that MVC was not appropriate for every application. Scott said there were a number of coming improvements for web forms model (although didnt say what they were).
The web forms model will not disapear because:
Web forms model is better for some types of applications, e.g. small apps, those requiring long processes that make use of view state useful
Many applications are using it
Many third party components developed for it
ASP.net implementation is not mature yet (although does seem pretty good so far)
Microsoft will probably announce a number of new features in PDC in a few weeks time.
Microsoft is finally coming to terms to one basic fact of development. You can't provide the ultimate solution to any problem. This is why MVC is being developed, and Scott Guthrie is clearly stating that MVC is meant for larger, more enterprise-y sites. Web forms will continue to exist and be developed as a simple, RAD-based approach to web development.
If you take a step back and review all recent improvements and additions to the Microsoft stack, you can quite easily categorize them between these two classes. For example:
Data access: LINQ-to-SQL vs EntityFramework
Remoting: WCF vs WebServices
LiveID: LiveID (web) authentication vs RPS authentication
...
I only hope that Microsoft will make this distinction clearer with time, because there seems to be a lot of confusion among developers as to what tool should be chosen for which task.
In conclusion, I think that Microsoft will keep on developing both because they cater to different developer profiles. Microsoft has obviously a lot of interest in growing its developer base as much as possible and to make the .NET stack as useful as possible.
I am going to go out on a limb here and disagree with the general idea that MVC is the "enterprise" framework here or is somehow the better of the two.
MVC is great! But just look at the name. It stands for "Model, View, Controller"... see the "view" in there?
Now look at the competition, "Web Forms"... see the "forms" in that one?
MVC does a great job in "view" type situations. For sites that publish content ("views" of information) MVC probably has an edge, especially for larger systems that need a lot of testing and very a formal design to support intelligent view switching.
For applications that interact heavily with the user via forms (data collection and data entry heavy apps) web forms has an edge due to the inherent use of form posts as a primary mechanism.
While you can do views with web forms and you can do forms with MVC, each has trade-offs. In the current state of MVC, I find that writing heavy data entry "views" is much more difficult and painful than with web forms... and I don't mean a little bit.
In the future I do expect to see MVC get better with dealing with data entry scenarios, but these scenarios will likely come at a pretty high price compared to doing those with web forms.
Neither is more "enterprise" level than the other as far as I can tell... what I'm most interested in going forward are hybrid applications that use MVC for the display and publishing end of the business while web forms are used more naturally for heavy data entry end... all in the same web project... I sure hope we see something like that.
Before word of the MVC framework started spreading, we spent a good deal of time at my company developing our own .NET MVC framework.
This was because we didn't want to be constrained by the limitations of the WebForms abstraction - we wanted to avoid the 'clunky' feel and user interface compromises that WebForms seems to impose on all by the most heavily customised applications. Also, we wanted friendly URIs and we wanted a better separation of front-end and back-end development than that offered by WebForms (we settled on an XML / XSLT architecture).
In my opinion, WebForms in fact offer a much poorer method of interacting with the user specifically due to the use of ViewState, PostBacks, etc etc that abstract the actual mechanics of HTTP from the developer - this gives them less latitude in how they allow users to interact with the system. The classic example is that because WebForms pages are almost always the result of a POST, if the user attempts to refresh the page, the user gets a nasty warning message from the browser. The pattern in the traditional web development world for dealing with this has always been to include a 302 Redirect directive in the HTTP Response, thus sticking to the original HTTP paradigm of GETs being for retrieving data, and POSTs being for sending data. Other, similar problems exist such as the inability to have two forms on a page (for example a login form to a website on a different server).
That said, for RAD, WebForms are brilliant. I'm currently developing the admin application for a webapp we've developed using our custom MVC framework, and I'm flying through since all I need is to display the contents of a load of database tables, and in some cases allow the user to edit them, in various different ways.
I think that if we need to convince ourselves that MS are going to continue to support WebForms - just think of all the ex-Windows developers. These are the people that WebForms was originally developed for, and they're not going away. Corporate developers will be your saviour if you're a WebForms fan.