It [the View] may also update the model by sending appropriate messages.
Doesn’t the Controller do that?
Jeff:
I’m glad to see some code in your blog again, I’ve no problem with home theaters, energy saving, multiple-core and Gps but man, we are developers.
The MVC and MVP patterns are a great arquitecture solutions but I’m totally agree with this.
“Personally, I get tired of all the arguments about whether a given architecture is really MVC - but HTML-CSS-Browser ain’t MVC. Get a clue.”
Good luck with stackoverflow Jeff, keep blogging!
Jeff:
I’m glad to see some code in your blog again, I’ve no problem with home theaters, energy saving, multiple-core and Gps but man, we are developers.
The MVC and MVP patterns are a great arquitecture solutions but I’m totally agree with this.
“Personally, I get tired of all the arguments about whether a given architecture is really MVC - but HTML-CSS-Browser ain’t MVC. Get a clue.”
Good luck with stackoverflow Jeff, keep blogging!
My only issue is that in the ASP.NET world is that MVC-ish approaches have been available for a long, long time. It took more work and there were obstacles in the Webforms model that required work-arounds, but it was possible. If your only goal is “separation of concerns” you should have been doing that all along, even back to VBscript classic ASP days.
I have been following Hanselman, Haack, and Conery since the first bits were made available to the community of ASP.NET MVC and while I love what I am seeing, I still can’t shake this feeling its really targeting people that never got a handle on the post-back model or controlling their viewstate.
Am I being too pragmatic by stating, who does this really serve? Because my users do not care if I employ “Model-View-Presenter” or “MVC”.
There seems to be many interpretations of how MVC works for web apps, but I think the one discussed by Jeff is definitely not common, and possibly wrong. Here’s how I see it:
Model
domain + data access, typically implemented in back-end classes using a middleware platform like ASP.NET, PHP, J2EE and such
View
In the case of a web app, this is typically the combination of HTML + CSS, and sometimes even Javascript (for things like pulldown menus). HTML is NOT a model, it is part of the VIEW.
Controller
In a web app these are typically the “clicks” in the application. The controller validates input, sends messages to the model and routes the view to the next page
I guess there are multiple ways to look at it, but the one above is what I see most in the industry. Seeing HTML as the model is by far the weirdest interpretation of MVC I have ever heard of.
I think the development world keeps trying to come up with the best patterns, which it should. Unfortunately, the pre-MVC ASP.NET world relies heavily on the FORM and postbacks, and there is often little “separation of concerns” in these type of web apps.
Can/should all apps be made using MVC? No. Is “separation of concerns” (beginning to detest this phrase already) a great idea, is having one place to change something the right way, etc.? Of course. A point to keep in mind is that in order to do “.NET MVC” you will have to abandon the FORM/postback “model”.
I think the development world keeps trying to come up with the best patterns, which it should. Unfortunately, the pre-MVC ASP.NET world relies heavily on the FORM and postbacks, and there is often little “separation of concerns” in these type of web apps.
Can/should all apps be made using MVC? No. Is “separation of concerns” (beginning to detest this phrase already) a great idea, is having one place to change something the right way, etc.? Of course. A point to keep in mind is that in order to do “.NET MVC” you will have to abandon the FORM/postback “model”.
Jeff,
I think your next post should be MVC vs. “3 Tier” in web apps, since I think this is where a lot of the discussion is going.
I remember reading up on the MVC model early on and trying to figure out how to merge that into my web apps and became a bit confused on how it would actually flesh out. I think the biggest issue arises at that boundary where the web form is updating it’s display based on a certain data column being set to true/false, or where the custom formatting of a GridView would go.
I took to the Presentation / Business Logic Layer / Data Access Layer and it had drastically improved my web apps for maintainability. I still wonder how things get retooled in the ASP.NET MVC model and what would be the pro/con of doing so.
Skinnability is a pretty superficial sort of view customization. It’s no stretch to imagine a system that would be skinnable and still not have proper separation of concerns; indeed, I would guess that many web apps qualify. Just beacause you can juggle fonts with CSS doesn’t mean that mixing and matching different chunks of data on one page comes easily.
Separation of concerns is important, but I don’t see the point in attempting to coerce existing systems into a model. Why not just look for the separation of concerns instead?
Because there’s more than one way to break up a web app to the the MVC model. In fact, in something like a blog, I think one could make a case that the database is the model, the HTML/CSS/browser is the view, and the scripts on both the server and the web pages are the controller. But what does that prove? What does it mean? How is that observation useful?
The main use I can see is that the view and controller are broken up into multiple disparate pieces and are consequently a huge pain to deal with. That is to say, web applications do not follow a clean pattern, aren’t particularly well-designed, and that they’ve succeeded in spite of that, or because they have other advantages.
“but HTML-CSS-Browser ain’t MVC. Get a clue.”
“Seeing HTML as the model is by far the weirdest interpretation of MVC I have ever heard of.”
I’m not sure why Jeff is taking such a beating here. I think there may be some misunderstanding.
He describes HTML+CSS+Browser as an example of the MVC pattern in action. To my mind he is entirely right. They certainly fit fairly well with the definitions given by Trygve in the article.
The entire point of CSS is the separation of data (model) and presentation (view).
But importantly (I think) he is talking here about how the components that make up a SINGLE web page conceptually fit together. He is NOT saying that this is how MVC applies to the architecture of your ASP .NET web application. That is a completely different of level of abstraction.
In fact when he does mention web apps later in the article he says that in ASP. NET the HTML is part of the View.
Another way to look at what you are saying is to keep your business objects out of your presentation layer. This is a hugely important concept as it allows your code to be highly portable, and you dont have to start from scratch every time there is a ‘latestgreatest Upgrade’. I am a .NET developer and we use CSLA which seems to completely follow this logic. I really appreciate the ability to write new GUI’s with so little code after the first time.
And to Shmork You would be surprized to see how well this concept works with .NET3.5 combining the power of Visual studio for a Developer and ExpressionBlend/Illustrator/Photoshop/Quark for the designer. The power of a presentation layer separate from the Business Objects allows the UI to be done in XAML and gives the developer one view while the designer and the rest of the world get a very pretty finished look.
Not to try and cross advertise here or anything, but is there any coincidence that this post comes the same day that Phil Haack is being interviewed on .Net Rocks about the MVC?
I’m off to listen!!! Need more input!
To those saying that XHTML/CSS/Browser isn’t model/view/controller:
I argue that it is MVC. The XHTML is the model, in that it contains the data you need to transform to display to the user(content of XHTML tags), and business-logic(the tags themselves).
The XHTML is view-agnostic - you could use a view other than CSS to transform it into a readable format, for example, an XSLT stylesheet could be your view.
The CSS is your view in this example - it contains information about how to get what’s in the model into a human-understandable format. It contains no actual business logic or data, it’s solely presentational.
The browser is the controller in that it facilitates communication between the model and its various views.
It’s definitely not a standard example of MVC, but if you think about it, it does hold. The instant you bring a server-side language into the problem it becomes more complicated and brings you closer to the typical example of MVC.
I find it interesting that, for one who proves again and again the simplicity of linking to other web sites and pages in the context of a blog post, there is no proper link to www.csszengarden.com. Screen shots of address bars just aren’t quite the same.
Love your site, love your posts, and hope that folks unfamiliar with csszengarden take a look at it.
Most of the people who are misunderstanding Jeff’s post here are thinking strictly in what they think ‘MVC’ is. That is, a web application framework ala rails,cakephp,django etc.
MVC is much more than that. It is a design pattern that goes beyond one architecture.
For example, MVC can be applied to a windowing file system:
Model: A file.
Controller: Ways to apply different actions to the file.
View: Could be anything, the view could be the icon to the file, or the file name, or even the files contents.
Its not just web frameworks kids 
Thanks a lot for this post…I was really not so clear about the concept of MVC before
What MVC tells you is that your data, logic, and how you present the two to the user should not be tied so tightly together that changing one means changing everything else in your program.
Remember, MVC is just a good idea, and not the law. My criteria is: Does following whatever model help clarify what you’re programming and makes it easier to maintain? If not, I’ll break that particular model – whether OOP or MVC. The whole purpose of a model should be to make your program better, easier to understand, and easier to maintain.
Then again, you shouldn’t break a model just because you’re in a hurry or lazy. Whatever programming you’re doing has to be maintainable. One day, you’ll have to modify the logic, change the way the data is handled, or change the way it is presented.
I still don’t agree with the case of a web page that HTML is the model and CSS the view. This may work for displaying data, but what about data input? CSS being the view cannot really model input forms. Sure, it can style it, but not really model it.
This means that your input forms (order of fields, field types, labels, etc) are likely to be part of your HTML, and not the CSS. Thus, the presentation of the input form is mixed with the model, being HTML in the example.
I believe that what you said about “skinnability” is true. Thanks for posting this wonderful article.