Friday, January 25, 2008 - Scott Hanselman and I were on the phone the other day talking about Community stuff surrounding MVC and certain ideas we had. The next thing ya know we're waving our phone arms and waxxing poetic as we try to phrase what we think the "MVC Story" is. We each have our thoughts and Scott wrote his up here. I thought I'd add mine as well because, overall, I think it adds to the ongoing discussion. To be clear: these are all my opinions and ScottGu and team worked up the MVC thing way before I cam on the scene
That's Comp Sci BabyThe room erupted with spilled drinks and laughter, tears and people holding their sides from laughing. It was at that time that I decided never to debate Scott in anything, ever. I might be right, everyone in the room might be in agreement with me, but Scott would still eat my lunch then throw the bag in my face :). I've gotten to know Scott better while working at Microsoft and I talk to him reasonably often on what we're doing. Getting more than two minutes of his time in conversation is truly a feat, and so far I've done it 3 times (woot!). And For Our Main Course: ASP.NET MVC Our conversation was pretty academic at first - focusing on perceptions of just what MVC is. It quickly devolved into office quotes, weird analogies, and metaphor as we discussed what we think is the core of what MVC offers to current ASP.NET developers. The question has come up a lot (this is from Rich Bushnell's recent post):
I don't need a complete new system for building pages. It just took me 3 years to learn ASP.Net as it is now. I don't want to throw it all away because it's not cool any more. And I don't think my customers want to do that neither <snip> Why not make ASP.Net better? Why not take the stuff in Patterns and Practices and make it simpler to understand... <snip> The real reason I'm peed off, is that I'm having to invent my own guidance, while MS seems to be messing about doing other things. That's not good for the customers, as they get new ideas from everyone, and no idea what is right or wrong. So guys, please. Why not stop what we're doing, take a step back, consolidate, learn from each other, and build something better than ever.You can tell that Richard is frustrated here :). It's easily understood - there's a lot coming out of Redmond these days and one thing that's lacking is what I like to call "The Story" - the Why, How, and When. In short - What's the Value of MVC? Would You Like Some Hedge With That Opinion? Before I go on - I want to reiterate that these are mostly my musings. No one has sat down and said "this is why we're building MVC". It, quite literally, JUST IS. I offer my thoughts here as to why I like it - and feel free to disagree. I think, if you take nothing else away from this post, please know this: ASP.NET MVC is an option for you. There are good reasons to use it, but it might not fit with what you and your company are doing. If that's the case - keep moving on the ASP.NET! A Drum, a Guitar, and a Rock Star Voice That's how people describe one of my favorite bands - The White Stripes. They were one of a group of bands that hit back in 2003 with the "Garage Sound" - unproduced, no fluff, no electronics - just raw four-track wundersound full of energy. Other bands that followed in this scene were The Hives, The Vines, and The Strokes and this movement was heralded as "The Second Coming" of Rock" That might have been a little dramatic, but at the same time there is a pretty nice response when your strip away the abstracted fluff and get closer to the core. Scott likened this to "ASP.NET Unplugged" and I think that's apt as well - you get to the core of what it means to develop a web application: slinging HTML and Javascript. Talking to Scott one-on-one can be ... interesting to be sure (but always entertaining) - in this case it was very enlightening as we ping-ponged our ideas and (what I call) stair-stepped our way to a pretty solid story - ASP.NET MVC removes a lot of abstraction (Web Forms) which on one can very much help you, but on the other hand (if you're an HTML specialist) can be a big help. Chiseling a Digital David While I was in Redmond last week I discussed this very thing ("the story" behind MVC and why it's appealing) close to 12 times. I kept struggling with analogies and I think I found one that works for me. It might not work for you - but I'm sincerely interested to hear what you have to say in this arena. Believe me - it's important! As a developer you build things- just like any contractor building a house, or artist creating a work of art. Often times artists will choose not to use tools that save them time, preferring to build something that they can (literally) work with their hands so they can "feel the art inside the medium".
In the same way that Big Z showed Cody how to shape a board ("looong, easy strokes") - many people just want the machinery to get out of their way when building a web site so they can create their HTML how THEY want to, and use javascript and form tags as they see fit.
Some people see this as tedious, repetitive work - others see the process as creationary and artistic. I think they're both right and I love how ASP, now, supports both.
I was in the conversation Scott referenced in his post about implementing a Repeater in MVC:
We need to come up with a Repeater control for folks using MVC... We have a Repeater - it's called a For LoopI want to share who said that line but I'll keep it close to my chest since it was said behind a closed door ;). What Do You Think? Part of my gig with Microsoft is soliciting as much community feedback as I can. I tend to believe that ASP.NET MVC allows for much more "hands-on" type of development with extreme control over your UI (HTML/Javascript) that allows you to create some really cool work. Do you agree with this? If not - what's the appeal for you? Does it frustrate you to have so many choices and if so - how can we help to provide some guidance?
As an enterprise developer, I place value on tools that provide improved productivity through use of ever-higher levels of abstraction. Requiring that developers hand-craft every pixel will not win me more points and exacerbates an already terrible recruiting/hiring skill availability problem. However, I recognize that there are some in the industry for which complete control is important and I can understand the appeal that the MVC framework provides in this area.
So, my concern is not there should be only one way to build web applications, but a concern over Microsoft's focus and their ability to support both frameworks over time. The industry as a whole does not have a good track record of a single vendor supporting two product lines that essentially do the same thing.
I have related concerns about P&P's focus and ability to support both. They seem barely be able to keep up with both the web and smart-client factories (working on one, then the other, alternately, for budget and resource reasons). Will they be asked to step up with MVC guidance as well? Can they do it? If they did, what would happen to the maintenance and improvements needed for the existing assets?
And what does MVC mean for Sharepoint, which seemed to be moving forward towards a highly-capable web application framework that moves beyond mere "pages" and integrates the concepts of record storage directly into the framework. All based upon ASP.NET. As one of ASP.NET's biggest customers, will it get the attention it needs if DevDiv is focused elsewhere?
1) Great implementation of the Front Controller pattern. Routing of requests is a great concept and I'm looking forward to seeing how it extends and matures.
2) Pre/Post Action - allows for near-AOP. I can implement my actions now and later come back to add authorization, filtering, logging, etc. This lets me focus on delivering a completed use case now rather than solving all of the horizontal problems first.
3) Goodbye post-back and viewstate. I love the control of using TempData for statefulness only when I need it.
Really MVC is just good OOP. We're separating concerns, following the SRP. It can be done with WebForms, but I like how with MVC you tend to fall into the proverbial "pit of success."
Great stuff. I and my team are on board and have tossed out our old web forms stuff in favor of the testability, control and good OOP practices of MVP. Keep up the good work!
That's right. For too long, the page (view) was the center of the universe. While this may have been sufficient some many years ago (before my time), that's no longer the case. We aren't building our father's web apps any more. People aren't satisfied with the web as a mechanism for simply publishing documents.
For many of us in the industry, the view is no longer the central theme. It has been debunked as the center of the universe. As a result, we are dropping the complexity associated with deriving all calculations, models, and formulas using the view as the center of the universe.
This discovery, the true nature of our universe, has lead us to embrace a new model. A model with multiple, independent bodies whose interaction ultimatly determines the present state of reality.
You can focus on MVC as a new way to do html, but to do so is to ignore the underlying reality. The view is no longer the center of the universe.
I would also like to challenge you to dig up some of the original material describing the MVC pattern. There's quite a bit of good material on the web about the pattern, but nothing quite like the original books describing it's original intent and goals. Yes, the MVC pattern has specific goals (beyond "separation of concerns").
If for no other reason than to read about MVC, I would challenge you to pick up a copy of Pattern Oriented Software Architecture (vol 1). I promise it will rock your world (or at least make you a better developer). If it doesn't, I'll be happy to buy your copy from you for the price you paid. (How's that for putting my money where my mouth is?)
Now, provide a decent REST/XML processor on top of this like ActiveResource and I can get rid of several other Microsoft specific http stacks like WSE 1, 2,3, asmx, WCF and SOAP in general. I'm hanging in here after many years of surviving the Don Box "COM is Love" era, which is now an enterprise interop disaster for us. This framework shows me some people still care about good design at MSFT. There is hope.
When .net came I saw that MS wanted a change in course so that developers have a better development environment. For some of us who did not come from CS background it was a steep learning and understand what OO really is , for many people like you it was more natural and but still the picture was not complete.
I really like the fact that MVC Framework is an option and not a change in course.
Some times I develop small sites as side projects. The client does not care if I use MVC or WebForms, they want something that will work. WebForms is good for that --- and even easier with SubSonic :). Value is measured in that you give them something that is not over engineered so that it won't cost more than it should.
The work I do most of the time is bigger in scale and testabililty is very important as these sites evolve. MVC Framework, TDD is great for that (and I'm still learning it). For these projects value is measured in that is not under-engineered so that it won't cost too much as the website grows in complexity.
Isn't the "acoustic" or "unplugged" version enjoyable because there's an original version in the first place?
As long as MS supports both MVC and WebForms (which I don't think why) I think is great.
At the end of the day
Personally, I feel the sort of tools required with this approach are IDE-based ones which quickly help you to write the code which can then be tweaked into a masterpiece prior to deployment.
A good example (albeit unrelated) are the DTO translation class creation tools in the webservice software factory.
Thanks for the quote. Glad to know you're listening. :)
I don't particularly care if we have another framework or not, to be honest. What I am more concerned with is the amount of stuff which seems to be left behind to make way for the new cool stuff.
I used to code in the ASP days. Using a ForEach was no fun. Try doing an alternating background color in CSS with it. Rails has a groovy function for it, and I hope the MVC framework will have, but without it, it's not easy. You end up with terrible looking pages.
I totally agree that ASP.Net is too complex. Patterns and Practices is worse. Why not focus on making that easier, in the same way we now have LINQ to make coding in C# and VB easier?
I'm glad we're talking about this though.
You know WPF and WF are 18 months old nearly, and, despite the hype we still have no tools, no controls, and no guidance on it. TechEd Barcelona had one stand for Silverlight, and no-one for dedicated WPF. WF is almost dead in the water, with nothing new coming out of it for ages. Is that what's going to happen to ASP.Net or MVC? Will Microsoft just forget about one of them too to concentrate on something even new and cooler than Rails?
Richard
It's probably worth pointing out, at this point, that I like to tease him. Because I envy him. I want to be him.
Did you leave this Hanselman?
We need to Keep It Simple if we are to develop web apps in a reasonable timeframe. The asp.net page lifecycle is ridiculous, all it needs to do is let you do some processing and render some html. The viewstate, postback-driven event model, databinding, evals which are not typesafe anyway, all just adds unnecessary complexity.
Ruby on Rails looks like the best choice to me for web app development. But this subsonic and MVC stuff is looking like a viable alternative to "jumping ship"!
I think there's a useful distinction to draw here between functional code (database access, domain model manipulation, business logic, etc) and presentational code (for each item in this list, write one data to the response)... I don't mind scattering presentational code amongst my markup; ASP.NET MVC let's me keep the heavy logic in separate assemblies and that's great.
The quote that got me most excited about MVC to-date has been from Scott Hansellman's screencast on the MVC framework when he said "You have control over every single angle bracket that comes over the wire."
That made my day; no more bloated IDs, no more needless span tags (and Repeaters have been the WORST offenders in this regard), no more ViewState clogging up my bandwidth.
Remember that clean HTML output is _not_ about artistic control; it's about low page weight, fast download times, and extending separation of concerns to the client (HTML/CSS/JS).
Out-of-the-box i can get an ASP.NET MVC site running with .NET LINQ on the back-end (almost completely covered by unit tests), with light-weight pages and simple, concise, maintainable CSS and JS on the front-end. With predictable class and ID names, i can draft site-wide CSS and wire up the JS library of my choice with ease.
Try and do all that in 10 minutes using Web Forms; i'm _still_ trying to figure out a good solid architecture.
I think that Web Forms was impressive in how it let you get simple dynamic pages and simple apps up quickly. Anything complicated, however, got real complicated real fast due primarily to postback and viewstate. The web is inherently not a stateful environment; trying to fool the browser (and the developers) into acting like it is came with a huge amount of headaches.
@Peter - in my eyes, ASP.NET unplugged (MVC) is ASP 4.0 in the sense that it brings the power of the .NET framework back to the simplicity of a basic Request / Response model.
I think "unplugged" refers to disconnecting from the viewstate/postback complications and to unplugging the dependencies to separate concerns front and back.
The ASP.NET MVC bits feel clean and fun to use.
Keep up the great work.