In the transition from classic ASP to Asp.Net some developers took to putting their server side code in a block at the top of their HTML ala:
<%# Import Namespace="MyDll" %>
<script runat="server">
void Page_Load()
{
}
</script>
This single-page model has some advantages as Jeff Atwood describes, however, in my experience I have seen nearly all code put in a separate code-behind file in recent times (ie with VS 2008).
Nevertheless, it turns out a colleague strongly prefers the single file (inline) method over the separate code-behind method.
What are the strengths and weaknesses of each approach? (I've noticed that code collapsing and #regions don't seem to be supported. Also the pages get rather long and there is no longer the visual separation of client and server side code. Can you tell I have a preference?)
I realize that variations of this question have been asked before, but I haven't seen anyone actually spell out specifically the pros and cons of each method.
EDIT
Thank you everyone for your thought provoking answers. I'm still hoping for a list of strengths and weaknesses of each method. What are the actual features that each has (or doesn't have)?
There's no doubt in my mind that the code-behind or mvc models are superior for almost everything you want to do. However, even today I still find myself using inline code for most of my pages. Why? Because there's one big scenario where the inline scripts really shine.
If you have a large amount of legacy ASP Classic code that you don't want to just throw out, including a deep nesting structure, it all lives in one big application, and you want to share that application with your asp.net code, you can just drop inline asp.net pages right in your existing web file system and they'll just work.
This sounds like exactly where your other developer is coming from.
Because codebehind is just a class it has all of the advantages like inhertance and interfaces. It also enhances readability.
Single page has mostly been replaced by mvc for applications that focus on outputting data instead of implementing businesslogic.
Have you considered looking at ASP.NET MVC instead? It will allow you to overcome this dilemna in a very clean seperation.
Generally, when working in WebForms, the trend I've seen is to use a code-behind. Many* WebForms applications that I've seen in the field have too much in their code-behinds, and the separation is almost critical just to be able to understand all the logic.
However, in a well-designed app where the UI is only doing a UI job, and passing all the logic and heavy lifting to a different app layer, a single-file solution will often end up being more elegant and easy enough to traverse. In a way, going with the single-file solution may -- in the right hands -- motivate a better separation of concerns, because you don't want that one file (which provides your UI) to get cluttered with a bunch of business logic.
In the ASP.NET MVC model, the default is single-file. This is, again, to stress separation of concerns and good application design. (I do not know off the top of my head if the ASP.NET MVC kit provides a code-behind concept. I have not used it if it does.)
Ultimately, YMMV. Good developers tend to write good code whether it uses the code-behind or single-file model. Bad developers tend to write bad code either way, too.
* Obviously not ALL!
Inline code is procedural in nature and lacks separation of concerns...
One of the selling points of ASP.Net was the the code-behind and the server controls. It was thought to be bad to have inline code. This changed when ASP.NET Mvc came on the scene -- inline code became "hip" again.
If I had a choice and all things being equal using the code-behind is a better approach. I strive to keep as much logic/code out of the UI.
Even using the code-behind, while it is a class, it can become a tangled mess. I found that using MVP or some variant of MVC with web forms made development more maintainable in the long run.
Related
I'm a new comer to the asp.net world. I hear a lot about asp.net mvc and it's advantage over webforms about the ability to customize the markup and css. I also heard that asp.net is much easier to learn than asp.net mvc so I decided to go for asp.net and webforms. My question is: what's the level of customization a web developer/designer can get with webforms concerning the markup and css?
You can have as much customisation as you like in the html output! You can customise everything in web forms. However, with customisation brings time, effort and room for error. All of these things is what web forms is trying to save you.
However, since you are just starting out I wouldn't worry. Just make your web forms how you want and forget the customisation of output (it is much better with ASP.NET 4 anyway). In a few years when you are more experienced then worry.
If you were going to customise everything then you should have gone with ASP.NET MVC - it is one of its main arguments. But there is nothing wrong with web forms. Particularly if you are beginning with asp.net in general I'd say it is better.
Standard ASP.NET WebForms uses server controls that generate the markup for you, so the level of customization is limited to what the controls you are using provide. There are techniques that allow you to override what is rendered by the controls and thus customize the markup and also write your own controls but it requires some coding. It is possible to achieve almost complete customization of the markup but it IMHO requires more efforts than a web developer should need to put into something like this.
While it is definitely possible to have a SEO friendly, unit-testable, maintanable, standards compliant application using classic ASP.NET WebForms, the efforts it requires will be significant compared to ASP.NET MVC. But if you don't care about those things you will be able to pretty quickly develop web applications.
ASP.NET comes with a set of built in user controls - things like text areas, buttons etc. These mimic winforms in how they are supposed to work (events etc), however this is a rather leaky abstraction (you must always remember you are working with HTML and HTTP).
The user controls allow reuse and when a page is built they emit HTML - you have little control over the emitted HTML (unless you override the rendering, which kinda defeats the point), hence the perception that they are harder to customize. It is not easy to get right either and requires more work than I think is worth.
There are also different compromises in the way pages are rendered out (ids for example end up as a long string of concatenated container control names) which make MVC a better choice if you are looking for control over your HTML.
Microsoft suggests that you pick the technology based on your needs:
While ASP.NET offers rich controls and produces quick results without great control over the markup (as mentioned: it can be done but somehow beats the idea behind ASP.NET and creates a lot of additional code), it suffers from the flaws mentioned by the other posters.
In MVC, there is a limited set of "out-of-the-box" controls and you'll have to code more on your own (including clientside JavaScript) but you do have more control over the rendered markup of your controls. In addition to that, your project will generally have a clean separation of concerns which benefits (unit) testing and maintainance.
Another aspect that hasn't been mentioned yet: In ASP.NET a page undergoes the so-called "ASP.NET Lifecycle" every time the client communicates with the server. The Lifecycle consists of several events that are fired in a special (and sometimes confusing) order. Handling those event in the right order in complex web applications is one of the biggest difficulties in ASP.NET and often leads beginners to forfeit. In MVC you don't have to deal with that kind of problem.
Therefore I strongly recommend that you take a look at the ASP.NET architecture before you start to code. Here is a very basic start: http://www.asp.net/learn/videos/video-6558.aspx
Personally, I started with WebForms and am now moving to MVC after I worked with the similar MVVM pattern in Silverlight and WPF for my bachelor thesis. This kind of did it for me so that I now understand the benefits and ideas behind MVC a lot better. Once you are used to WebForms, switching won't be that easy though.
So the bottom line is that we are working on a large web based project in ASP.NET webforms that is extremely heavy on data editing operations and we are not getting the code reuse that we want out of the presentation layer. We are currently generating a good portion of our DAL and that works great. However, the strategies for standardizing, improving UI development time, and code reuse for the presentation layer are less clear. I have been researching DyanamicData, potential code generation, and writing our own custom controls, but i dont see an obvious place to focus our efforts. Any strong feelings on these directions?
Thanks,
Matt
I have been doing ASP.NET development for several years... and I have yet to see any sort of tool that takes the hassle out of UI work in the same way that code-generation tools can make short work of the DAL. Personally, I don't even use the Visual Studio designer view. Every app is different... and has different UI requirements.
I do have a general rule for doing webforms though... (but it also applies to programming in general, and you probably already use something similar) If I need to do a UI task twice... I cut and paste the code. If I need to do it a third time, it goes into a UserControl.
Are you new to ASP.NET? If so, know that UserControls are your friend... it is the go-to method for presentation layer re-use in ASP.NET. CustomControls are a trickier beast.
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
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 :).