Understanding Model-View-Controller

CSS is definitely the View

Well, if you make HTML the model, then CSS is also part of that model, IMO.

CSS does not do anything to HTML in and of itself. That job is done by the rendering engine. CSS is extra information that it uses. So if you’re using MVC to write the rendering engine, both the HTML and the CSS are in the Model. If either changes then the View (eg the display in the browser) has to change.

I find it useful and illuminating to think of the interaction of
HTML/CSS/Browser as an example of MVC

I find it confuses the issue, because it’s not an example of MVC :slight_smile: I think there are far clearer examples. There would not be this disagreement if it was a good example.

Hey Jeff -

Does this mean that now that you’re independent again, that you’ll be returning home to your VB roots and be switching back to VB.NET?

Or have you fallen head-over-heels for C#? :expressionless:

Inquiring minds want to know! :-))

I heavily discussed this with my class mates today. We all think the ‘HTML/CSS/Browser’ example is highly inappropriate in the case of a proper MVC model.

It’s not wrong, it’s just a bad example.

MVC is not just easy to understand but also is OBVIOUS and almost every program will meet with it.
All program have some part that “do things”, other part that “show things” and other that you can “operate things”, MVC just ask for separate those part on a “not-so” isolated space.

Anyways, a skinned application usually are MVC “complian” and a skinned-less application still can be a MVC one.

@Jim:

Well, if you make HTML the model, then CSS is also part of that model, IMO.

But HTML models a Document. CSS doesn’t model anything, it only describes how the HTML is presented. A “presentation filter” as Trygve put it. Changing the CSS doesn’t add content to the document. It is used to “highlight certain attributes of the [Document] and suppress others”

To take a more common example, let’s say you decide to model an Invoice using a collection of BillingItems, then you want to present that to the user using a data-bound table (e.g. DataGridView).

That table has a LOT of extra information (Properties) that controls which columns to display and how to format them, what font to use, colours, border styles, padding, margins etc etc - but all that information is still part of the View, not the Model.

As per your argument, if either (the contents of the Invoice model or the properties of the table) changes then the display must change. But again that doesn’t mean the table properties are part of the Model.

Interesting, just been learning about MVC Architecture in the context of EJB’s. From what ive learnt the pro’s of using this software abstraction of buisness and application rules far outway the negatives. Sounds like this is the way to go.

I think the examples in the article are very flawed. html css etc are bad examples, because they run everything together.

HTML and CSS include elements of all parts: model, view AND controller. It is impossible to complete divorce the HTML from the view. And the HTML ALSO (partially) defines the interface for receiving data from the user, in conjunction with the browser. And CSS can modify that interface as well. And I think if CSS is being used to store information about images, it can be considered to contain model data.

“The controller decides what the user’s input was, how the model needs to change as a result of that input, and which resulting view should be used.”

I don’t think this is accurate either. As I understand it, the controller is an interface between the user and the view. The view decides how to change the model, not the controller.

I think for a bunch of people reading a programming blog many of you
fail to see the abstraction that Jeff is trying to point out

I, for one, understand the abstraction; I’ve been using it for years. However, his example is flawed

But HTML models a Document. CSS doesn’t model anything, it only
describes how the HTML is presented. A “presentation filter” as Trygve
put it.

I disagree. CSS is not a View in the MVC sense.

The very first sentence of the definition of a View is:

“A view is a (visual) representation of its model”

CSS is not any sort of representation. I can even override certain elements of it with my browser settings - does that also make the browser the View? It’s supposed to be the Controller in this example.

Also, how does a Controller talk to CSS if it’s a View? Nothing ever talks to the CSS, it’s just data (which is why I put it in the Model).

In MVC there is an interaction between the various parts (although IMO it’s better if the View never calls the Model directly). CSS never interacts with anything. It is never a representation of the model, visual or otherwise. Instead it is used to create a visual representation.

The problem here is that the example is flawed, and the 3 things Jeff listed do not map to the MVC pattern. So while HTML could be considered (part of) the Model, the other bits don’t fit neatly.

The conversation about fitting View properties into MVC is interesting, but too long for here.

I’m new to programming. In school, we were hammered on 3-tier. MVC was discussed as more a philosophy than a practice. 3-tier was the way MVC was implemented in RL. Is this an accurate or fair assessment?

Thanks, that was a simple, but very helpful explanation for those of us who aren’t OO masters!

It’s a little dangerous to say that the controller is the brains, especially to people who are not steeped in the Smalltalk way of thinking.

A lot of an application’s brains should actually be in the model. Large controllers and skinny model objects are a sign of what Martin Fowler calls the Anemic Domain Model antipattern, where your model objects verge on structs, and a lot of domain logic is in the controllers or in function libraries.

The solution, pushing a lot of behavior back into model objects, is well explained in the book Domain Driven Design by Eric Evans.

Remember, kids! Object = data + behavior. If your data and behavior are separate, then you’re not doing OO programming even if you’re using an OO language. Instead, you’re doing “procedural object-oriented programming”, or POOP.

I think the best web based example one can make of MVC (in a true stateless web environment) is this

Model: Database
View: Browser
Controller: Application Server

The data being passed around with this is not that important… but what is relevant is that the user interacts with the browser, which sends messages to the application server, which updates the database, and then sends new model data to the browser to be rendered.

When you throw Javascript into the mix it gets a little more complicated because the browser can twiddle with the model on its end, so for the sake of explanation, the above example is simpler.

The most thorough description of MVC that I have found is in the book A System of Patterns by Buschmann, et al. This is the book that provided me the ‘Aha!’ moment where I finally grasped that MVC does not imply that any of these layers should not collaborate with both of the others. It is more about segregating the responsibilities of each layer and defining some rules about the work each performs.

If only CSS didn’t suck…

When I was studying computer science, we were told a completely different kind of MVC. Especially what controller and what view is seems to be swapped in your example.

The Model:
The model helds the data to work with. The model could be a database table, it could be a piece of memory with data or in many cases in modern apps, it is an object with instance variables and methods to work with those variables and the object properties as a whole.

So far describing HTML as model seems accurate. But …

The View:
The View presents the data to the user. The view interacts with the user. The view is stupid. It does not understand the data. It does not even know how to display the data correctly: It needs to be told how to display the data and how to prompt the user for input! Basically a browser window with a simple render area in the middle and some menus is a view.

So if this webpage is a model, the browser you are using to view it is … a view (hence the name view, you “view” the data with it).

And finally…

The Controller:
The controller is the one who understands the data and relationships between different data types. It has all the logic, all the knowledge. And it knows what to tell the view, so the view can display certain part(s) of the data if requested and return user input if desired, which the controller will take care of to handle.

In your example, CSS is part of the controller (it tells the browser how to render the HTML). Any JavaScript in the page is controller two. But the browser itself already has a build-in controller, that set-ups menus, takes care of mouse and keyboard events, and so on.

We could argue days which perspective of MVC is better, your one or mine. However, mine pretty much covers with what Wikipedia says :stuck_out_tongue: Have a look at the Pattern Description and how the three terms are explained there:

http://en.wikipedia.org/wiki/Model-view-controller

It’s late, but for any of you young whippersnappers who read this article and don’t get the peanut butter+chocolate reference, http://en.wikipedia.org/wiki/Reese’s#Marketing_and_advertising

This is probably a bad analogy, because chocolate + peanut butter is a good thing. I’d suggest the edit:

“you’ve probably gotten your model’s taco seasoning in your view’s Miller Lite”

You can have taco seasoning and Miller Lite at the same time, but they need to be separate.

Other than that, good article :slight_smile:

-von

I really must get around to messing about with XCode and Interface Builder properly. I am spoiled by Delphi and latterly VS2005’s WinForms designer and the sugary ability to double-click on the button to tell the app what to do when the button is clicked.

Not to be pedantic, but what exactly do you mean “skinnable?” Are we talking about the Winamp Classic style of skinnable, where you can manipulate the style to your heart’s content but the layout of controls stays pretty much the same, or the Winamp Modern style, where you can literally rearrange everything into a brand-new design?

Does skinnable mean that you change your sidebar navigation model to a multi-level tab implementation, or is it sufficient separation of concerns as long as you can change the banner and font sizes without turning the entire page into a hideous mess?

I’ve seen MVCs that I would hardly call skinnable… and I’ve seen lots of skinnable apps and sites that definitely aren’t built on any MVC template.