ASP.NET MVC - WebForms Unplugged
As a new Microsoft employee, I like the new-found pragmatism at the Microsoft Developer Devision, typified by projects like the ASP.NET 3.5 Extensions and MVC. Certainly we all know MVC as a concept is nothing new, but it is new as a philosophy for the ASP.NET team (IMHO).
Remember that ASP.NET WebForms render using a Control Hierarchy which is fundamental to the whole gestalt of what we think of as ASP.NET. You put an <asp:label> inside an ASPX page and as soon as you mark it 'runat="server"' you've added it to the Control Hierarchy. Any string literals around your control also become part of that hierarchy of objects. The PreRender event is an opportunity for you to affect that tree of controls before the Render event fires and they turn into Angle Brackets (usually HTML). ASP.NET represented a swinging of the needle, as it were, from the Classic ASP way of doing things to an artificial event model that gave us state where there was no state. It added layers and production value and it sounded good, and still sounds good to lots of people.
However, this leaves a gap in the music. Sometimes I just want to control the stream myself. I want the system to step aside and let me get down to it. Not all the way aside, but certainly out of my general field of view. MVC Frameworks with View engines like ASP.NET MVC and Monorail's many template options and the Django template language and HAML...
(Note to self, write HAML view factory for ASP.NET MVC. UPDATE: Crap! The brilliant Andrew Peters made NHAML this last month and added it to MVC Contrib. New Note to self, crush Andrew Peters for being too awesome.)
…provide a fresh clean new sound to the same old angle-bracket-based music of the past. Clean, simple, lightweight.
Is it MVC that makes this possible? Partially, but we mustn't forget the huge influence of sites like http://www.csszengarden.com and the minimalist markup aesthetic promoted by CSS folks and standards wonks changed the way we think about markup and what can be accomplished with a few H1s and a UL/LI or three.
In a recent MVC design meeting someone said something like "we'll need a Repeater control" and a powerful and very technical boss-type said:
"We've got a repeater control, it's called a foreach loop."
Zing! That's so cool. Get out of my way and let me make some angle-brackets. Again, not for everyone, but for enough people that matters. Open Source projects like MVCContrib and hopefully a bunch of 3rd party component vendor types will drink in that simplicity and the power of statements like that and create helper methods and controls that we want, need and can use, and not just <mvc:TooBigDataGrid/>.
This is a not just a different tune, but a whole different band playing all new music. Not everyone will like the music, and that's why the world has more than one band. This is a Good Thing.
I like to think of ASP.NET MVC as the raw, acoustic version of the more heavily produced and multi-layered ASP.NET WebForms we use today.
I hope the pure intent and zen-like simplicity of a nice clean MVC design stays that way. Sometimes I want to listen to Kanye West, but sometimes I want to listen to John Legend. Or, insert your own musical analogy here. Either way, it's ASP.NET Unplugged as far as I'm concerned.
- ScottGu MVC Presentation and ScottHa Screencast from ALT.NET Conference
- ASP.NET 3.5 Extensions - plus MVC How-To Screencast
- DevConnections - The ASP.NET MVC Framework
- DevConnections and PNPSummit MVC Demos Source Code
- Hanselminutes Podcast 55 - MonoRail as Alternative ASP.NET
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
Someone should take that other developer to the side and explain just what MVC is, the philosophy behind it, and perhaps have them run through a few Rails demos, not to mimic it but to understand the MVC philosophy and that's it's not about a palette full of repeaters and adapters and extra layers. That every attempt should be made to add as little as possible to the framework, fewer layers, fewer indirections, fewer controls, fewer interfaces.
I like to think of ASP.NET MVC as the raw, acoustic version of the more heavily produced and multi-layered ASP.NET WebForms we use today.
That's just dead on!
The thing that I love about this blog post is that you're addressing the why of ASP.NET MVC. There's a lot of how out there, and no clear explanation of why you should look into this raw version. I think it's crucial to get this message out to the those ASP.NET devs that haven't fully grok the power of ASP.NET as a platform, not just a control framework.
Like always, Scott, you've done a great job in getting this point across.
I am a web developer from past 6+ years. Started out with ASP and moved on to ASP.NET which started with the 1 beta and now 3.5.
I agree with all the people in the world why we needed MVC. When i first laid my hands on the bits and did the Northwind, one thing thats struck me was this is much more easier and fun to do now. There is a very well separation between your layers.
But, one thing i feel is: Should the view be plain old scriplets or Should views make use of the controls? Why am i saying this? Because, we all know that ASP pages gave us a night mare as the page grew. Yeah spagetti code is what we used to say. So again if we are doing the scriplets in the views i believe that as your page grows you are going to see the same things spagetti-ness. Rob's HTML helpers are very cool. No doubt about that. But i have done all the examples that you and scott have been showing us using the ServerControls in my views and i do the databinding from code behind. All i see in my view is a neatly indented tags. Well this is always a debatable factor because somewhere i have read that the main reason why we use scriplet in ASP.NET MVC views is to avoid populating the control tree and that will speed up the rendering. Well this is my personal view and not to offend anybody in anyway.
happy coding :)
I'm going to be brutally honest but it's just my perspective, if someone doesn't know how to write proper HTML (hopefully XHTML) and CSS then they have no business writing web applications. MVC is actually the anti-VBScript of web development while WebForms was basically VB for the web as it attempted to coddle developers, forcing a square peg (event model) into a round hole (request/response) so people wouldn't have to think too hard or learn too much.
We all have work to do, I just honestly believe for certain types of web applications MVC makes that work go faster. It's easier to test, faster to get up and running and you have less hacks to deal with. It's a sentiment you hear from almost every developer that goes to the Rails camp, that the MVC pattern has made them more productive.
True, there is a lot out there but part of why I'm a developer is because there is always something new to learn and that no one can ever know it all, even in development languages I've used for over 15 years I still find new things and I think that's great. Plus, things like AJAX are super simple to learn, it shouldn't take more than an afternoon to learn enough to put it to use, same with ListView and Nested Master Pages, especially nested master pages, they're all of 30 minutes to learn and you really should be taking advantage of them if you're going to stick with WebForms.
I really love the new concept of the ASP.NET MVC, but there are some things that could be streamlined to help the developer.
Using a control, like the Repeater, instead of <% foreach... you get that nice clean code/content-separation. Just because you can do stuff on the OnLoad or OnDataBind doesn't mean it's not that clean aucoustic experience.
The MVC can still render that clean HTML, customized to the very core by the developer, and still be helpful and productive.
On your view of the 'why?' behind MVC I couldn't agree more. As much as ASP.NET WebForms simplified web development for .NET developers coming from a WinForms / stateful background, I still wish we had frameworks like Spring / Spring.NET and MonoRail that would force developers to understand what's happening under the hood at least to some level. That's why I'm so happy to see the MVC framework show up in our ecosystem.
Lets separate two things.
First there is viewstate bloat and postback hiding of the web forms. It causes lot of issues, but hopefully we will get rid of them with mvc framework.
Server controls are separate thing. They are reusable components that simply work and make my development much faster. Why shouldn't we have them in mvc too? On the asp.net forum, lot of people have already asked for them (and they used the term 'component' instead of 'server control' probably because of the RoR). Please don't be exclusive. Web forms are not all bad. Reuse the good things and avoid the bad ones.
Personally I like the repeater. It is very lightweight controll. And I don't like the 'curly braces for loop' in my view page.
A really good post on the subject from Ian Cooper: http://iancooper.spaces.live.com/blog/cns!844BD2811F9ABE9C!533.entry
MVC: Model View i have Control again!
I don't think it's a question of not knowing how. More of an issue of not liking to do it. As sole developer (stake holder, PM, developer, DBA, Tester, QA, janitor and craft services) on every task I do, the more I can rely on reusable controls the better. The further away I can get my code from the house of cards that HTML is, the better.
Having said that I do think the fact that MS has put this on the table is a very good thing. Making me stretch my notions about different methodologies is a very good thing. And with these two paradigms living side by side in a more visible way than before, will hopefully eventually lead to a chimera of sorts.
Mike - I think you make a great point. For LOB apps, you'll be hard pressed to beat WebForms for raw productivity. I'd say that WinForms vs. WPF is another good example where one might be better for LOB and one might be better when you need to be more flexible.
It is not as if MVC is some really hard concept that requires MS expertise in order to implement. The only real value that I see Microsoft bringing to the table is the ability to quickly tap into Visual Studio to provide a rich editing environment that takes advantage of the VS extensibility model, and the ability to leverage their relationships with other consultants and ISVs to support the MVC framework early on.
I am not against the MVC framework - just against this view that seems to exist that somehow people are "forced" to use postback/viewstate model when that is in fact not the case at all.
I've jumped from companies to companies, and I rarely see webforms being used even remotly as intended. Nevermind in creative and more efficient ways. It is, in my opinion, like when Object Oriented Programming came out. Until the "Design Pattern revolution", it was a huge mess of soup, and people would run back to procedural programming (using static methods if they were using a fully object language).
A lot of the problems i hear, from performance issues to viewstates, are often from teams (not individuals, so please no one get offended!) that just Don't Get It(tm). WebForms are NOT the VB of the web: that is, its not a braindead RAD technology, it is actually one that you need to study and understand. Once you do that, your apps are fast, efficient, and you develop much faster than you would in MVC. But that means you actually need to have some kind of architecture... WebForms, while they "feel" high level to the untrained eyes, are only a foundation... You need to build something on top... the simplest probably being an MVP pattern. But in general, people bypass that step, mix up MVC idioms in it, have business logic tightly coupled with the Code Behind... its a huge mess.
Thus, I stand by the fact that WebForms with MVP (or something) and a component and event based model is a superior approach: the MVC framework will be great however, until that approach is better understood. In the same way as when memory handling became a very understood problem, Garbage Collections surfaced, WebForms is an example of what we get once the Web becomes more and more understood... embrace it, don't go back to C and pointers for doing front end applications :)
If you can't answer this question, then you probably should not use MVC for creating anything, especially a complex business app.
Any complex business app should have its domain logic in the model, and ASP.NET MVC doesn't tell you what to do here. This framework gives us VC and expects us to provide M (the MVCToolkit notwithstanding).
I'm pretty familiar with the MVCToolkit integration with Dynamic Data, and I believe it would be difficult to develop a complex business app using it out-of-the-box. I'm not sold yet on the partial method approach to implementing business logic. But with NHibernate, IdeaBlade DevForce, LLBLGEN, etc. you can build a solid Model on top of which MVC will sit nicely.
MVC is full of SRP, Front Controller and Request Routing goodness. I'm sick of relying on Page Controller and direct calls to ASPX pages. Controller first, I say! Because any good MVC junkie wants just that: complete and utter control.
There is only thing I have a problem with:
If you write the Raw HTML in your View then that means you have to handle all the browser incompatiblies issues in your code, right?
It's especially a problem with WAP sites.
I'm working on a WAP application with ASP.NET and the markup generated by is good enough that the site is usable on every mobile device that the ASP.NET recognized (I'm using the WURFL ASP.NET intergration kit which works very nice).
It might not give me the best results for each device, but if the other option is that I have to manually write the WML/cHTML/XHTML... and manually optimize it then I'll just continue using ASP.NET.
MS, stop thinking like MS, think out-of-the-box and look at what works on other platforms that would work very well on .NET...Rails maybe, or maybe Rails. Did I say Rails?
That sounds intriguing. Is there any video walkthru out yet that shows how to best accomplish that with an MVC approach?
Amen... or not...
And that's the problem I have right there with WebForms, you have to first undo WebForms and then rebuild a new framework on top of it. A lot of people did just that but it always felt like swimming upstream. Hence the reason a lot of really gifted developers jumped ship over to RoR.
@Ryan Smith, "As sole developer (stake holder, PM, developer, DBA, Tester, QA, janitor and craft services) on every task I do, the more I can rely on reusable controls the better. The further away I can get my code from the house of cards that HTML is, the better."
I hear you, I also wear a lot of hats, that's the nature of consulting. One thing to remember is that controls and helper classes are still a part of MVC, it's just how they integrate into the rendering flow and page lifecycle. I agree it would be nice to get away from hand-coding HTML but even with WebForms you still need to often hand-edit the emitted HTML if you care a lick about web standards or moving away from table-based layouts. These aren't just pie-in-sky web design idealism either, I know a developer that went from stock WebForms controls to hand-crafted XHTML/CSS and reduced his page size from an average of 4,000 KB to 894 KB, which translates to real-world bandwidth savings and customer perception of his site.
@Francois Ward, "Once you do that, your apps are fast, efficient, and you develop much faster than you would in MVC."
That is completely subjective and I'd challenge you (in a friendly context of course, we're all just developers here looking to write the best code) to back up those claims with proof. For every case you put up I have one of someone launching a successful app very quickly and efficiently using MVC, whether it's Rails-based or one of the other MVC-style frameworks. In fact what you hear most often from those in the Rails camp is just how productive the MVC framework has made them.
One thing to remember is that some people aren't just excited about MVC because of the pattern but because it also works within the context of what the web is vs. trying to change the web to fit it into another ideal. MVC acknowledges that the web is stateless, that there is no such thing as a button click event on the server and that it's all request/response. WebForms wouldn't have been nearly so scarring for me if it hadn't broken so many web conventions and standards, like you don't mess with an html element's ID and that you allow more than one form element on a page.
Anyway, the challenge is not ASP.NET nor MVC nor... you name it.
The difficulty is that we have to deal with HTML, DHTML, XHTML, WAP, JScript, VBScript etc. and none of the browsers are really compatible. And to be honest: That's all crap - nothing is state of the art. (At least the days of VHS video are over! ;-) After how many years?)
My proposed solution: Get rid of all the old crippled standards, throw away all browsers and start from fresh and do it right! - Unlikely? - Yes! - So I guess we have to stick with the idea that developing for the web will never be easy. Sorry guys!
I say pick the right tool - sometimes ASP.NET, sometimes MVC extensions, sometimes Web Client Factory, Rails or whatever - for the task at hand.
MVC is not a silver bullet...
Clean divs and a nice JS library can get you pretty far, actually. It's not as bad as it was in 2000, but it's still lame, I agree.
Comments are closed.
I think someone beat you to it.