ASP.NET MVC - WebForms Unplugged
Sponsored By
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.
Related Posts
- 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
About Scott
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.
About Newsletter
Hosting By
I wish we could just have a nice clean testable version of webforms. I like server controls and I like ASP.NET Ajax as it stands. I also don't see how we can creating a complex business app using ASP.NET MVC.
Find that boss type and buy them a bottle of whatever libation they love and put it on my tab. Seriously, the whole reason I love MVC, and the frameworks that implement it like Rails, is that it feels simple, clean and works with-in the context of the web's stateless request/response paradigm instead of trying to shove a big fat desktop event model on top. Ever see that movie "Mary Reilly" where Mr. Hyde whispers her name in the darkness and she shudders in fear? Whisper "ViewState" and you'll see quite a few web developers react the same.
WebForms always felt vaguely insulting, like training wheels for web development, as if your basic developer wasn't smart enough to grok statelessness, request/response, HTML or JavaScript. It also was a pretty big middle finger to anyone that cared about writing standards-compliant websites. The CSS adapters? Classic over-engineering, I know how to fix it, let's slap yet another coat of paint on top of it!
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.
WebForms always felt vaguely insulting, like training wheels for web development, as if your basic developer wasn't smart enough to grok statelessness, request/response, HTML or JavaScript. It also was a pretty big middle finger to anyone that cared about writing standards-compliant websites. The CSS adapters? Classic over-engineering, I know how to fix it, let's slap yet another coat of paint on top of it!
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 think the coolest thing with the MVC framework is being able to quickly whip up the IttyBittyGridThatDoesExactlyWhatINeedRightNowAndNothingElse.
I just love this quote:
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 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.
Re: "We've got a repeater control, it's called a foreach loop." What about the HeaderTemplate, FooterTemplate, and SeparatorTemplate?
I haven't had a chance to use it for real yet, but just installing it and watching the screen casts and reading about it are enough to give me warm fuzzies. Very exciting stuff. And if you need any help, ping me. I just got laid off. Job hunting... Ugh!
Scott,
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 :)
regards
Lohith
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 :)
regards
Lohith
I like the Repeater and it's bigger cousins, controls like DatsList and GridView. No more OBO errors. No more building HTML. Some of this MVC stuff smells like VBScript... and on top of that, I have work to do! How can I be productive and learn SilverLight/WPF, LINQ, AJAX, MVC, Nested MasterPages,ListView, arghhhhhHH!
//TILT//
//TILT//
I'm not sure if Andrew is being sarcastic or not (damn intertubes, you loose all sense sarcasm) but on the off-chance he is serious I think he brings up some interesting points that I hear echoed in the community, about not wanting to write html, about liking everything easy, about all the technologies, etc.
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'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.
Yeah Ok, we get it, MVC rocks. But when I first tried it out I found it really tedious. Also, I can't figure out where to put stuff, how to name my controllers and actions. I just can't get into that frame of mind, have I been poisoned?
I don't know, but I have to deliver a LOB app in 3 months and it's gonna be webforms all the way. I got that treeview up and running in 5 minutes and I'll just pretend it's not a big bunch of tables and silly javascript. All in all, there's something strangely productive in webforms, and if you take into account updatepanels and such, MVC has a loooong way before it can win my heart. It's not helped by the way Microsoft is structuring the development with the main devs asking on a forum what they should do next.
I don't know, but I have to deliver a LOB app in 3 months and it's gonna be webforms all the way. I got that treeview up and running in 5 minutes and I'll just pretend it's not a big bunch of tables and silly javascript. All in all, there's something strangely productive in webforms, and if you take into account updatepanels and such, MVC has a loooong way before it can win my heart. It's not helped by the way Microsoft is structuring the development with the main devs asking on a forum what they should do next.
No, I agree with Joe Chung and Andrew.
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.
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.
So at last, we got the Struts in ASP.NET Core as well LOLs. In my View you hit the nails Scot as me too feels some time annoyed to follow the suite given by me ASP.NET. (As unfortunately i have started with CGI-Bin World so love to went into the details).
On an extremely technical point, it is 'Kanye West', without the H ;) Good music taste btw ;)
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.
Gabor
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.
Gabor
I feel urged to comment.
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.
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.
I might have forgot to mention in my last post: 'frameworks coming from Microsoft and the kind of abstraction that still requires to have a good understanding of what's going on is what I was missing.'
A really good post on the subject from Ian Cooper: http://iancooper.spaces.live.com/blog/cns!844BD2811F9ABE9C!533.entry
A really good post on the subject from Ian Cooper: http://iancooper.spaces.live.com/blog/cns!844BD2811F9ABE9C!533.entry
And I forgot, to use your analogy, if you have ever watched MTV unplugged, although all instruments are acoustic, base guitar stays electric. You simply cannot get a good sound without electric base.
The important thing - to me - about MVC - is that now ASP.NET offers BOTH development paradigms.
dang... that didn't turn out quite right. Let me try again. :)
MVC: Model View i have Control again!
MVC: Model View i have Control again!
"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."
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.
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.
Oop! Sorry, re: Khayne != Kanye...my mother-in-law is named Khanye, so I type that name a LOT more, so there you go.
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.
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.
Everyone complains about ASP.Net getting in their way with the whole postback model and viewstate. Personally, I view that as a red-herring. If you don't like the page event model - don't use it. Nothing forces a developer to uses pages or controls. They could write their own web-framework on top of the core library using the HTTPHandler interface (after all an ASPX is just one type of HTTPHandler). The Asp.Net team is doing it with MVC. Visual Web-Gui did it with their framework. People have always had the ability to use a simple "for each" repeater in the existing framework, whether as part of an ASPX page or inside their own HTTPHandler. The fact that they choose not to do so says more about them than it does the actual framework. So please stop blaming ASP.Net. If you use the page framework, that is solely your choice - MS has provided the necessary tools for you to get as close to the metal as you desire ever since ASP.Net 1.0.
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.
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.
One thing I see that because MVC has been around forever, and WebForms are fairly new as a mainstream technology (it was there since .NET, but it wasn't used much, so we can more or less use .NET 2.0 as its birth), it is quite misunderstood.
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.
Once you get it though, the code is beautiful, using functional programming paradigm and component based architecture, there's a full separation between the technology (The "Web") and the architecture, so you don't need to worrie about the platform. And best of all, I don't have to always think about validating unintuitive things like List items (Like validating if the client used javascript to add invalid options to it), as the webform model have very clean methods of dealing with these things.
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 :)
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.
Once you get it though, the code is beautiful, using functional programming paradigm and component based architecture, there's a full separation between the technology (The "Web") and the architecture, so you don't need to worrie about the platform. And best of all, I don't have to always think about validating unintuitive things like List items (Like validating if the client used javascript to add invalid options to it), as the webform model have very clean methods of dealing with these things.
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 :)
seerox says: "I like server controls and I like ASP.NET Ajax as it stands. I also don't see how we can creating a complex business app using ASP.NET MVC."
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.
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.
And using MVC doesn't preclude the use of server controls. I've made some pretty powerful server controls for abstracting the creation of things like detail views and grids. But I have complete control of the rendering because I created the server control from scratch. MVC doesn't spell the end of server controls. I think at its core it is a shift in thinking where behavior comes first, and visual presentation second. This is reversed in a page/view first approach and makes agile development more difficult.
I've played a bit witth MVC framework and it looks very nice.
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.
Nadav
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.
Nadav
The MVC is still early yet and it needs some design taken from Ruby on Rails. Scott, I would like to see "zen-like simplicity" but I don't get that from the current incarnation of Microsoft's MVC. Rob Conery is soliciting feedback and I have a few ideas of my own, http://rbazinet.wordpress.com/2008/01/27/what-i-want-in-the-microsoft-aspnet-mvc-framework/.
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?
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?
Jeremy D. Miller said: "I think the coolest thing with the MVC framework is being able to quickly whip up the IttyBittyGridThatDoesExactlyWhatINeedRightNowAndNothingElse."
That sounds intriguing. Is there any video walkthru out yet that shows how to best accomplish that with an MVC approach?
That sounds intriguing. Is there any video walkthru out yet that shows how to best accomplish that with an MVC approach?
"We've got a repeater control, it's called a foreach loop."
Amen, brother
Amen, brother
We've got a WebPage control, it's called for, foreach, StringBuilder and string.Format
Amen... or not...
Amen... or not...
@Joe Brinkman, "Nothing forces a developer to uses pages or controls. They could write their own web-framework on top of the core library using the HTTPHandler interface..."
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.
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.
Oh, now MVC is the hit again? (Anyone remembers Smalltalk?) How about Web Software Client Factory? You get MVC and ASP.NET server controls.
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...
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...
Joern - I don't mean to take the wind out of your sails, but I agree with you 100%. MVC is just another way to make Angle Brackets, but the Angle Brackets we need to make are still too complex, and HTML 5 isn't helping things, IMHO. Personally, I'm liking NHaml more and more just so I don't have to see another angle bracket. I try to use things like MS Ajax or JQuery to hide from browser complexities, and that's about it.
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.
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.
Scot-- I downloaded the MVC samples and worked on them , and built a small demo. It was great . However I had a strange feeling when I was going through the sample code provided by you. Is ASP.NET going back to the inline coding model , that was there in classic ASP ? or it is there becasue this MVC build is highly volatile ,as you have mentioned in your videos. Obviously I know that it still supports the code-behind model and I've been able to code a view in code-behind.
Comments are closed.
I think someone beat you to it.
http://andrewpeters.net/2007/12/19/introducing-nhaml-an-aspnet-mvc-view-engine/