There are lots of articles and discussions about the differences between ASP.NET WebForms and ASP.NET MVC that compare the relative merits of the two frameworks.
I have a different question for anyone who has experience using WebForms that has since moved to MVC:
What is the number one thing that WebForms had, that MVC doesn't, that you really miss?
Edit
No-one has mentioned the WebForms validation controls. I am now working on some code that has a few dependant validation rules and implementing client-side validation for these is proving slow.
As a PHP/Classic ASP person, I ventured into webforms world about 5 years ago. After having to handcode things like table grids, calendars, etc, in scripting languages, it seemed like webforms would be a tremendous helping-hand. It was...that is until you need even a slight bit of customization beyond alternating row colors and the like. Yeah, you could have a gridview running with a few drag-and-drop motions. But customizing even what would seem like a simple thing could turn into hours of torture and research.
I also think a lot of the examples given in .NET online are oversimplified for the effect of making webforms look "easy". Sure you can get that gridview to show only 10 records of a 100,000 record table, but do you realize that ALL of the records are being loaded into memory by default? As an example of the over-complicatedness of rectifying that problem, I spent a while creating a pageable gridview that only loads chunks of records, but it wouldn't work. After an hour of research, I found that you had to delete an extra property that the IDE inserts into the codebehind. Not fun when stupid stuff like that sets you behind.
And at every turn, it happens.
Don't even get me started on viewstate.
But then the clouds parted, and .NET MVC was handed to us. Now THAT is a framework. If you are a web developer, you should know whats happening when someone makes a request to your webserver. The abstraction and layer of cruft that webforms put on top of that is a disservice.
For the most part, I'm able to develop applications at the speed of PHP scripting and FINALLY have TOTAL control over the UI. That's what it's all about.
And as an additional note: People need to stop complaining that they are creating "tag soup" in MVC views when they find they have to use <%= %> tags and the like. Drag and drop your gridview onto the page, set all the properties, then view the crap it gives you. And your not nearly done yet, now you have to attach events and put more gridview-related code in your codefile. Talk about messing up the coding experience. I'll take a simple foreach loop anyday.
nothing :)
I really like the way ASP.NET MVC works. I want to control my HTML. I don't need controls. We can get the same functionality with HTML helpers and third party tools, e.g. jQuery and all the available plugins.
Here's an example on how to use a gridview-like with jQuery grid on ASP.NET MVC.
Although Ruby on Rails is a more mature framework, I do think that ASP.NET MVC is on the right track.
I miss the gridview, the simplicity of getting built in sorting and paging in with very little effort. I use grid functionality all the time and have still not found a good alternative in mvc
Well I do miss something :
the ability to have a pageable grid in seconds.
Although it wouldn't be very fair since I also had to create a class to feed to the ObjectDataSource to have an efficient pagination. And also the pagination would work only with the JavaScript on or I would have to write code to read the QueryString (for ex. &pag=2 etc.) and so on.
In fact... I guess there isn't much too miss.
The simplicity of having only one form on a page. I think the html form functionality is kind of awkward and not very intuitive and I guess there is a good reason why the webforms creators tried to abstract away form handling in webforms.
One difference, which I am sure will be rectified over time, is the expansive amount of reference material and examples online for web forms versus the relatively sparse amount for MVC. However, one could argue that a lot of the material on web forms covers topics such as the page life cycle which MVC no longer makes necessary (thank goodness).
Until now nothing really.
I definitely miss MVC every day at work while I look at the ugly WebForms code I want to wipe it all out and now make everything transparent, clean and beautiful.
Of course only time will show whether the new girl is really better than your old wife.
As crazy as it sounds, I miss the calendar control. Not for datepickers or that sort of thing, but for scheduling apps where you want to show a full page month-at-a-glance/outlook style events calendar with selectable or clickable links that you inject via the day render event.
If anyone knows of an MVC alternative, please share! Rolling your own in this case is doable, but kind of a pain.
Viewstate is the thing i miss - until i remember problems it causes.
Then i bend my mind and look for another approaches (smarter model binding, ajax etc.) which usually turns out to be better (but slower to find & implement).
The main thing I miss is the documentation. WebForms, because of it's relative maturity, has a lot of official documentation and also a lot of 3rd party examples and snippets available. However, this is improving all the item and, as MVC gains momentum, I hope it will be on a par.
Nothing as well.
WebForms do so much automatically but frequently I had to hack it to suit my needs.
MVC let me do what I want and I can hack it to get things done better/faster.
I love to control the output and prefer clean, lightweight style.
Output Caching is not really implemented in ASP.NET MVC (as of version 2). There are tricks to get it working, like using Web Controls with the OutputCache directive, or using WriteSubstitution, but all these tricks go against the nature of MVC in some way. Output Caching for anything other than entire action methods is really tricky to get working in ASP.NET MVC, and always induces enormous technical debt. Since Output Caching, especially in the newer versions of IIS, is incredibly performant compared to data layer caching, this is a shame.
simplicity in Dragging and dropping controls.
might be seeing some of this in the near future maybe in mvc4
Reference :- http://www.codeproject.com/Articles/808297/Things-you-will-miss-in-ASP-NET-MVC-as-an-ASP-NET
I will not say i miss because all the changes are happening for good. But yes i would miss the below
The lovely server controls who just give output in a blink.
The behind code file.Double clicking and going to the Code behind for some reason made me superior.
Viewstate magic.
Now i need to get in to headache of POST and GET.
Related
What were typical problems during developing on ASP.NET? So, would you like to describe typical problems/mistakes during developing on ASP.NET from your experience?
UPD
I have been working as ASP.NET developer for 2 monthes.
The biggest mistake in my opinion is that many people do not take the time to learn and understand the framework before they begin coding. This often leads to solutions that do not follow the intentions/paradigm of the framework.
My biggest issue was the page lifecycle. When you start adding Masterpages & user controls, it gets a bit tricker figuring out what happens and in what order
When you say ASP.NET I'm assuming you mean WebForms.
The biggest problems are related to DataBinding, event handling, viewstate and control id's. These concepts are entangled in complex ways that start to break down whenever you take even a single step outside the beaten paths.
WebForms was built to provide a similar experience to web development as to desktop UI development. After years of ASP.NET WebForms development experience I think I can safely say that WinForms does not live up to the promise. The attempt to hide web specific concepts (like the fact that HTTP is stateless) means that you as developer loose a lot of control, which makes it hard to figure out what the problem is when something does not work as you'd expect.
For anyone starting .NET-based web development I suggest you get intimate with more modern web development platforms like the ASP.NET MVC or MonoRail. The initial learning curve may be a bit steeper but when you get rolling you'll be much more productive.
Most of the asp.net web forms problem has been overcome by asp.net mvc framework. The problem in web forms were many. The biggest i feel is it has only one form. others are misuse of viewstate, which later overcome by control state. Web form has complex page life cycle specially if you are dynamically adding user controls etc.
On the other hand i see no problem in asp.net mvc framework.
I think most common mistakes on developing not only in Asp.net is that when you try to study something or just a part of it and feel like you need to stop because you think you know everything which is obviously wrong. For me Asp.net is like the world because when you know the continent of Asia,Europe,etc. it doesn't mean that you need to stop because you already know a lot of things. I think it's not that way because Asp.net have so many capabilities that every developer can explore like me who is also still studying and when you learn something, like me most of the time I say hey I never thought this exist in the map of Asp.net and again I say hey you know what I learn something new, I wonder if my previous project applies to what I learn today. Things like that, I learn in every step and the ladder never ends.
I think making a statement about your background/experience and knowledge of Http, Html etc. might help people give a better, more meaningful response.
Typical problem #1: Master pages. Coming from classic ASP, this concept was new to me so I learned how to use it properly in "the hard way". In the beginning I tried to change things defined in the master page from within content pages which is obviously wrong.
Typical problem #2: User Controls. The classic ASP does have "include" mechanism allowing the programmer to put repetitive blocks of code so I was familiar with the basic concept, but combining it with existing Page, learning the different life cycle and understanding the real power of the custom controls took long time and many bumps on the road.
From my point of view,the biggest problem in considered to the state management.
The people often get confused what to use on a particular situation.
Next one is most of don't know about the page life cycle well.which is most important during custom controls and all.
And the most important thing is new comers often don't know how to actually indulge oops concepts while software development..
I have read several other posts here, so i get the idea on the pro vs. cons, especially having full control over the rendered html code etc. (in MVC).
My question is regarding the UI controls: In MVC, i will have to write all UI controls myself (or the html equivalent). Now is that not going to be very difficult?
The reason why these 3rd party vendors for asp.net are there is just because of the fact that it is difficult to write UI controls for ASP.NET all by ourselves, and be able to target to all web browsers, and also that we are better off concentrating our time on the business logic rather than spending the whole lot of time writing the UI controls HTML code ourselves.
I understand that this feature gets us the full control over the final html, but is it not counter-productive to do this UI bit ourselves. If it was so easy to write them ourselves, how come these 3-rd party vendors are all living now. We could have done this all by ourselves all these years of WebForms days.
I am sure i am missing something here or being a little stupid, but please enlighten me as to what i am missing in specific regard to the UI bit being written by ourselves.
Just because i get full control over the program by writing in IL code, do we go and do that? We still use C# and things like that - So that theory of "having full control over html" - i am not bought into that idea.
Please help in getting my head around this UI bit.
Other things i understand, about the separation of concern, TDD based development possible with MVC etc.
But why would i go around writing the UI controls all by myself - it is a bit a work isn't it?
The thing is:
If you want to master in web development you have to master HTML + CSS + Javascript
And with WebForms you have to learn the WebForms way to do it, but with MVC you have the power of .Net with the freedom to generate the HTML + CSS + Javascript you want.
Here's a new rant on the subject http://www.charliedigital.com/PermaLink,guid,6dcb0333-9d70-40c7-975b-0ff4011c4661.aspx
Problem is, ASP.NET MVC is much younger product than ASP.NET. For many years 3rd party companies have been developing TONS of reusable components, and I believe that it is only a matter of time before comparable set of controls will be available for ASP.NET MVC.
If you really need very rich GUI with 3rd party controls, and you can't rewrite them in acceptable time - stick with asp.net. Altough in my opinion, MVC gives you tons of power it wouldn't be wise to spend much more time rewriting controls than you can save. If you can live without controls, and like MVC concepts - use MVC, and you'll most certainly see 3rd party solutions as soon as they'll there is growing market (maybe thay've already noticed that, I don't know) for mvc extensions.
I believe that the UI and the user experience are vital to the success of a web app. Making the page intuitive and easy to use, minimizing the amount of navigation the user has to do to get the job done, and providing effective feedback and interactivity can make all the difference between a site that users want to use and one that they avoid.
If you are trying to attract users on a public website, a pleasing appearance and excellent usability are key to building repeat visits.
If you are writing an intranet app to be used by hundreds or thousands of employees all day long -- as I mostly do -- making the UI efficient and easy to use really means a lot to your users.
So, I wouldn't downplay the importance of the UI. It isn't a nuisance. It's a key part of the user experience. I suggest that a web developer should embrace whatever tools and strategies that will get the job done. That often means coding the UI controls yourself. Or working with a teammate who likes doing that part of the work.
I recently refactored a very complex website using ASP.NET + handworked javascript to MVC + jQuery. The complexity of the code was reduced by 50%-75% and became much more testable. I replaced all the complex webcontrols I had to write (with a steep learning curve I had to overcome) with very simple HtmlHelper methods.
Don't forget, when you use custom webcontrols, you are given a very static UI by the control developer. With raw HTML, you can take advantage of styles and ui developed by the whole web industry.
Increased simplicity, decreased development time, testability, flexibility in UI... I don't want to go back.
You also have to remember that ASP.NET MVC is just the first release. I don't think there is intrinsically any reason why you couldn't have the equivalent of server controls to enable certain tasks - remember, there are many server controls that don't generate any mark-up (such as the Repeater, PlaceHolder, ListView). These type of controls could be useful in a future MVC setting, I think.
I believe that ASP.net came around when lots of developers were still used to doing desktop applications and just beginning web development. AT that point in time abstracting the details of the web with controls and post backs was a great way to get people started. At that point we weren't trying to perfect the web, we just wanted to get on it!
Now that the web has matured and we've all slowly learned about html, css, javascript and the likes we want to optimize our websites for our own needs and we don't want to depend on ASP.net Forms controls to control the fine details of our websites.
In summary, I think this is about the natural evolution of many developers from the desktop to the web
I for one, am very thankful that you cannot use ASP.NET controls in MVC.
Controls, as many have already pointed out, are just server side blocks of code that render HTML and javascript on your behalf. Things like a datagrid are great, until someone asks you to make a slight modification, like having a delete confirmation alert, and then it seems impossible to do certain tasks.
The good news is that there are very powerful jQuery tools written to help you. jQgrid is a great grid replacement that does WAY more than the ASP.NET grid...
http://www.trirand.com/blog/
jsTree is a treeview that is fantastic. Again with the jQuery....
http://www.jstree.com/
And the truth is that most things you can do with razor, HTML, javascript and CSS. It's so simple that it's just stupid.
It's hard for people like myself who were web forms developers to grasp MVC and why you should use it because it's so simple. It's difficult to let go of the complexity of conventional ASP.NET. But it feels so good when you do.
And don't mix web forms with MVC. You can do it, but you will wish you hadn't.
Here is the key thing that I think you are missing. When ASP.NET is no longer the MS way of doing things...you will eventually be forced to move on and do something else. I have programmed in perl, ASP classic, then ColdFusion, then PHP, then ASP.NET web forms, then ASP.NET MVC...the only thing that they all have in common is the underlying database, design patterns, best practices for a given set of technology AND...HTML, JavaScript, CSS, and Photoshop.
No one is asking you to learn MVC. No one is telling you to not use WebForms. However, complaining that you have to write a raw UI is not going to get you very far in this industry. You should be learning something new every day...and it sounds like some time spent on HTML and CSS would be a great place to start your focus!
The biggest problem you have with relying on third party controls is when a client asks you to do something that the third party controls don't cover. If you can't replicate their complexity plus the added feature request on your own you are skirting a possible failure in your professional livelihood! You will need to know how to do it all...eventually!
I generally suggest that you embrace new technologies. You don't have to use them...but you should at least know how. This way you will know what the best tool is for any given project.
I've been wondering - what's an equivalent of 'control' from webforms in asp.net mvc? It's not a partial view for sure. What else it can be? Controller + partial views via partial requests?
Maybe i'm dumb, blind or both, but i haven't seen any 'control' for asp.net mvc. Just a lot of code snippets to accomplish one specific thing or another.
I believe that asp.net mvc is quite unfriendly with rapid development. Only way out of this problem - a lot of open source code (like MvcContrib), tutorials, sample applications & most important - slightly smarter developers.
You do not have to replace Webforms controls with something else from MVC. Just mix them - http://www.hanselman.com/blog/PlugInHybridsASPNETWebFormsAndASPMVCAndASPNETDynamicDataSideBySide.aspx
Well, I was also wondering how to use 3rd party controls in ASP.NET MVC. Obviously, and contrary to some answers here, it had to be possible.
As much time has passed since the question was asked, the industry has evolved. So I've searched and found (but havent' yet tested) solutions such as Telerik Extensions for ASP.NET MVC .
I'm posting this answer here mainly to support other MVC newbees such as myself - Just Google
"asp.net mvc" controls
For months, I've been considering downloading Microsoft's express web platform and learning ASP.NET, which I might actually enjoy, seeing as I already do web work with PHP, but am much more comfortable with C#.
However, the primary reason I don't want to do this is that I've always associated ASP.NET with useless spaghetti HTML. The link I posted is an excellent example. Would it be possible to use ASP.NET in a context more similar to PHP, using it to power my site but not leaving the HTML, CSS, and JavaScript to be done by hand for validation and semanticity reasons?
EDIT
I've decided I'm not going to learn ASP.NET and stick with PHP.
While MVC sounds nice, for me it will likely end up being a development/debugging headache.
Things get much better if you use ASP.NET MVC. I recommend you skip ASP.NET WebForms and jump to MVC directly.
If you are going to use Classic ASP.NET Web Forms, you really need to learn how it works to avoid truely ugly html. If you know what you are doing, you can get close to what you want (you can't completely get rid of ViewState & it will do some ugly thing with element IDs)
A lot of the ugliness of Classic ASP.NET occures when people write web forms like they wrote VB 6 Windows applications.
ASP.NET MVC is a good option. It may be the way to go as a starting point; I would like to switch to it myself. I guess my point is that you can get less ugly HTML using Classic ASP.NET.
you're really going to want to check out the asp.net mvc. it allows you to develop in a manner a lot more suited for the web than vanilla webforms.
First of all, ASP.Net, even using webforms, does allow you to have complete control over the markup output. Of course it's easier for some cases than others, but anywhere you find you're not getting the html you want out of a control you can always replace the render behavior with a ControlAdapter.
That said, as others have mentioned you'll probably find it's much easier to get the exact html markup you want using ASP.Net MVC.
MVC.net and WebForms are built upon ASP.net
You can get a decent amount of control with webforms by disabling viewstate and not using any controllers (or very few). Its all in how much you let it do for you
If you are looking to acquire skills in the latest and greatest, then MVC is where you should start but I would also consider whether you will ever be asked to support ASP.Net Webforms. Having an understanding of ViewState is crucial to that end.
For fine grained HTML output, you can produce this in many different ways with classic ASP.Net. There is a growing group of developers who are using a mixture of ASP.Net and microtemplating with Javascript to produce RIA's. This inevitably leads to keeping your html output cleaner so that it can be manipulated with jQuery and CSS.
Learn ASP.NET MVC as it will give you more control over the html generated. Also learning ASP.NET will increase your job opportunities significantly.
My first real development in ASP.NET was with MVC, and I must say I truly miss it now that I'm onto the next project using webforms. Each has it's place and webforms is working pretty well for what I'm doing (also using it as an opportunity to learn about TableAdapters and what not) but I really do miss being able to insert the data I need right into the HTML. That way I know the layout I've built won't get screwed up.
As a framework I enjoy ASP.NET quite a bit, but the controls on the page seems so far removed from anything resembling HTML that there is often a mental disconnect with what I'm typing with what I'm expecting to see. I was that way when I first started HTML though, so I imagine I'll get used to it. When I started with MVC it was overall a much more enjoyable experience coming from a front-end background.
I’m new to .net, though I’ve been writing in classic asp for years. I know it’s time to make the change, but I can’t stand how bloated the HTML becomes.
For example, a simple menu using a web.sitemap and adds over 100 lines of JavaScript and HTML. A simple form with server-side validation adds in masses of ugly JavaScript. And a basic table of data using GridView adds in a ViewState that makes my eyes water.
Call me a purest, though I don’t like sending data to the browser unless it’s needed. And I don’t need a form-riddled menu when a simple unordered list of links will suffice.
So, set in my ways, am I destined to forgo the benefits of the Framework entirely by insisting on writing my own, cleaner code for everything? Or am I missing the point?
As a brief aside I’m a big fan of Campaign Monitor, a newsletter distribution company. They’ve written an elegant and comprehensive user-interface in .net without a single ViewState or bizarre .net-mangeled ID reference. Even the Sign Up form on their website (/signup.aspx) is as clean as a whistle. What’s their secret?
I hope I not the only one. Any advice would be greatly appreciated.
Try ASP.NET MVC or one of the other MVC web frameworks for .NET
If your GridView doesn't need it, then turn ViewState off for it.
Also, please edit your question to say what version of .NET you're using. Some of this gets better, and some does not. You might also want to try VS2010 beta 1, and complain about anything it doesn't fix.
Another idea would be to go on treating ASP.NET like it's classic ASP. Do it exactly the way you're used to, but do it with the idea in mind that there's about 10 years of development work that's gone into solving some of the problems of classic ASP. Once you actually hit one of those problems, find out if ASP.NET has solved it, and how.
For instance, I have a hard time believing you enjoy writing FOR loops to generate table rows. If you get tired of that, learn to use a Repeater control, or a DataList control, or even the old DataGrid control. If you turn ViewState off on those, I think you may find the generated HTML to be acceptable, and you'll find it a lot easier to generate tables and other structures that repeat based on repeating data.
You can opt-out of much of that bloat by not using all the out-of-the-box controls that come with it but I prefer the MVC route that activa suggested
Here is my list:
Keep the use of asp controls to minimum
Turn off Viewstate when it's not need
If you don't want the JavaScript associated with Client Side Validation (with ASP.NET Validation) set the EnableClientScript to False
Use asp:literal instead of asp:Label
Yeah it seems to be that everyone is bashing webforms at the minute for the reasons you have outlined above. HTML heavy Controls, ViewState, no control over ClientIDs all seem to cause an issue with people.
However let is be said that you can use asp.net (webforms) and produce some decent applications.
Control of html is yours through httpModules and httpHandlers and some of the issues mentioned above are fixed in asp.net 4.0
I just listened to a great podcast comparing MVC and webforms. Its in the area you are asking about. Also check out this blogpost by a dotNetNuke regarding the good asp.net code and why people should take a breath before converting everything to mvc.
Having said that I've tried Asp.net MVC and it is awesome. I'd probably look at dotNetNukes code to as its a mature asp.net product.
Also, when you do want to use these newfangled server controls, check out the css friendly control adapters. They clean up much of the bloat.
For client IDs the key thing to remember is to let the framework handle them. If you need to get an element on the client side, remember to emit the control's ClientID property into your script.
I've been using a template system and am very happy with it. Basically write an http handler for .html files and put tokens in the html files that regex could find in one sweep and inject any stuff. (google template c# for more info).
I tried some of the supposedly cool new features of ASP.NET for a little while. I also didn't like most of them. I felt constrained to work within the limitations of the common paradigms Microsoft had dreamed, even though I new how easy it would be to produce the HTML and JavaScript myself to do specifically what I wanted to do without having to learn how to jump through the hoops of so many new Microsoft-specific idiosyncrasies.
Anyway, I stopped using the parts of ASP.NET I didn't like on new code I've been writing lately. When I first started using ASP.NET, nothing in the MSDN documentation jumped out at me about how to avoid such complications, so I posted a couple "Hello, World" at http://www.agalltyr.com/rawaspdotnet.html to help spread the heretical word. I couldn't care less if it's the latest cool technology or the recommended technique. It's a reliable and reasonably efficient tool I can use to do my work.
Oh, and I'm not in the mood to learn ASP.NET MVC either. That's just more idiosyncrasies. Give me a language (C#) and a framework (.NET), and I'll design my own abstraction, thank you.
I've now completed my first web application using ASP.NET MVC and overall, I still am not grasping why this is getting all the praise and glory. Maybe I'm being stubborn. I know that what makes MVC great is that is forces separation between the presentation layer and the business object or data layer along with its stateless operation. I also know that when you are working with the view, it appears that the code is less readable (see my example below).
So I guess my question is... If the separation is the concern, why not just separate.
Web Forms View Code:
//UI
<h2><asp:Label ID="lblPageHeader" runat="server" /></h2>
Web Forms Code Behind:
//CODE BEHIND
this.lblPageHeader.Text = myObject.Header;
MVC Code View:
//UI
<h2><%= Html.Encode(Model.PageTitle) %></h2>
MVC Controller Code:
index = new Index
{
PageText = sb.ToString(),
PageTitle = "WELCOME"
};
return View(index);
Again, I might be being stubborn, but one of the things that I really liked in WebForms is the ease in setting object properties like DataSources and Text values. It seems like this is completely different in MVC and less readable which makes me wonder about long term maintenance.
EDIT
After looking into the typed models, I think the readability of the code is substantially improved.
ASP.NET MVC Best Practices, Tips and Tricks
I would write:
<h2><%= Html.Encode(Model.Title) %></h2>
(it's possible with a help of typed views)
instead of
<h2><%= Html.Encode((MyApp.MyObject)ViewData["PageObject"].Header) %></h2>
I think it's all about how you use it. If you're more happy with classic ASP.NET, than maybe it will be a better idea to stick with it. Moreover, you could also take good stuff from ASP.NET MVC world (like UI and Logic separation) and bring it to the classic ASP.NET.
What's great about ASP.NET MVC is that is doesn't try to hide how HTTP works. To fully understand ASP.NET MVC you need to understand the technologies of the web.
While webforms are adequate as long as you work to their strengths, they're ultimately a very leaky abstraction when you don't. While the drawbacks of viewstate have been well discussed by this point I think it's the extremely unwise attempt to mimic the behaviour of Winforms that is the underlying flaw - viewstate is merely a product of that.
The web controls which ship with ASP.NET also leave a (hell of a) lot to be desired as anyone who has tried to build an accessible website can attest to. The web controls show a total lack of understanding for how frontend development is done, and frankly are a disgrace.
With ASP.NET MVC all that nonsense is done away with. You're not shielded from HTTP, HTML, CSS, or JavaScript - if you come to the party with those technologies the framework gets out of the way and lets you leverage them. If not, then thankfully it doesn't try to help you to pretend they don't exist.
Not a complete answer, but one big concern is testability of ASP.NET Forms, or the lack thereof. Testing the UI logic of what gets displayed and how. With ASP.NET Forms, you are left to just the codebehind.
Now, MVC isn't for everyone. You may want to look into MVP (Model-View Presenter) for ASP.NET Forms as it uses very similar MVC concepts, except the Presenter is in control of changing the view's internals.
But, testability is really a big plus for testing your code. Such as whawt happens when someone clicks the ChangePassword method/action:
[TestClass]
public class AccountControllerTest
{
[TestMethod]
public void ChangePasswordPostRedirectsOnSuccess()
{
// Arrange
AccountController controller = GetAccountController();
// Act
RedirectToRouteResult result =
(RedirectToRouteResult)controller.ChangePassword(
"oldPass", "newPass", "newPass");
// Assert
Assert.AreEqual("ChangePasswordSuccess"
, result.RouteValues["action"]);
}
}
One thing (out of many) that I like about MVC is that it gets rid of Web Server Controls. While they are seen by many as a great thing about WebForms, I have found that once you get past the basic operations they become a nightmare. Trying to juggle databinding events on grids with postbacks and everything else becomes the OO version of spaghetti code.
MVC will require you have a better knowledge of the basic tenants of web development (GET, POST, REQUEST, HTML, CSS, JAVASCRIPT), the result will be much better. See my graph of how I think MVC works :-)
alt text http://www.baseestate.com/webformsmvc.gif
It's true that you need to do more in MVC to get some of the same basic VERY automatic functionality you became accustomed to in WebForms.
However, in the long run you end up with more control.
The main thing broken about WebForms is the whole PostBack scenario, and how many hoops you have to jump through to implement something simple WebForms didn't think of. One excellent example is my WebForms-related question:
Is there any native way in ASP.NET to do a "success message"?
I wanted to make a "Record Saved" or "New Record Added" message in a WebForms application. Turns out you have to do some really scary stuff just to get this simple functionality to work, because they don't have a normal way to do this in WebForms, and to do a custom method, you're fighting against the hidden functionality in PostBack.
In MVC, this would be no problem. You'd still have to write the functionality manually, but you'd have much more control over your page state.
I believe you can only feel the difference after you've been in a big project and seen how much mess WebForms approach could cause.
When you've seen a page contains multiple components, user controls, some of them living independent lives like hiding/showing or enabling/disabling themselves, all these rules passing through multiple control layers which cannot be traced until you've been in a project for many long years (or at least have smoked something reeealy good before diving in with the debugger :) ), you begin to appreciate the possibility for a clearly defined flow of control when you see how your data defines what components with what properties are rendered on a page.
I've also loved WebForms for a long time. I also disliked first few weeks/months MVC for exactly same reasons you put forth. After I've done some coding and could compare the experience, I began to enjoy MVC.
Still, there are some areas where MVC approach would be much more complicated and create more mess than WebForms would.
It'll come with time. Not really a long time. :)
Of course a simple example is going to be very clear and readable no matter how you do it. Supposedly, MVC's advantage becomes more apparent as you scale up the complexity.
Also, it turns out that the webforms model just isn't that great for high-volume public internet sites. ViewState plus the expensive page life cycle in a normal web forms site can make scalability a challenge (not impossible, but challenging). By contrast, on an intranet site users generally have much greater upstream bandwidth (ViewState works better) and volume is much better controlled. So webforms really works great there.
I'm also taking a wait-and-see attitude about ASP.NET MVC (along with the Entity framework and WPF for diff reasons). I'm a huge fan of MVC in general but am a little concerned about wrapping something as general purpose as a web development framework into the constraints of one pattern. A very useful pattern but still only 1 of many.
A skilled developer can implement MVC in practically any language. So MVC may be a great way to prevent less-skilled developers (we're all this at some point, like when just learning a framework) from making egregious mistakes. Since the pattern works well in a wide range of scenarios that could make it a net benefit.
On the other hand, for expert developers it may turn out to be like training wheels on an olympic cyclist... Redundant and more of a pain than a boon.
I think it very much depends upon your background. If you're already familiar with something like Ruby-rails and/or Django, asp.net mvc makes much more sense.
Also if you have been doing websites in Html and css for a long time, Mvc is much better as you have full control over your html output.
If you're comfortable with asp.net just keep using that, it's not going away :).