Thank you for posting this, Jeff. I’ve been trying to understand MVC for some time now.
Beware the kid with the new hammer, everything’s a nail.
Those that are currently rabid about patterns be forewarned: The book that spawned the term (Gang of Four) was groundbreaking at the time, but more of an exploration of a metaphor than the rulebook some organizations have made it.
The hypothesis: Is it possible to create programming “jigs” that would allow programming “craftsmen” to solve problems rapidly. Are there some fundamental building blocks upon which greater applications are built?
The metaphor applies about as often as you’d expect: 50% of the time.
Keep in mind that human minds are hard-wired to find patterns among chaotic structures, and programmers are better at it than most. I got into patterns long after I started programming and found (to my surprise) that I had been using the concepts without knowing for many years.
Would a better model in this example be XML? How can HTML (a markup language) be a good example of a model (data)? I thought the model in MVC was supposed to be view independent.
“For example, you shouldn’t use IMG tags but instead replaceable DIVs.”
I don’t know if I should laugh or cry.
Again with the giving credit to only Smalltalk people! We owe everything to lisp doggone it!!!
Okay, deep breath, I feel better.
Seriously, thanks for this article and breakdown. I would argue, as one other poster did, that the browser contains both view and controller. The CSS handling and page rendering is, I believe, view logic not controller. The linking etc is definitely the “routing” portion of the controller.
@Noah Slater: as dbr clarifies above, using DIV (or other suitable tags) instead of IMG does actually make sense when the design element in question isn’t (semantically-speaking) an image.
This is why I am a fan of this blog. I’ve had this very same discussion in my head a while back.
What I don’t like about the original definition of MVC is the link between the View and the Model (how a View “attaches” to a Model). I tend to, as Jeff did in the rest of the post, detach these two completely. Only then, I think, can your app be truly “skinnable.”
The View should be “dumb”: some meaningless (domain-meaningless) interface through which it receives data and barfs it on the screen and into which it can take user input and barf it to the Controller.
The Model is the domain model plus data access. Straightforward.
The Controller is…everything else. Receives the domain-meaningless barfed output of the View, fiddles with objects in the Model, determines the next View to be displayed and displays it, passing more data to the View via the domain-meaningless interface.
That way, whether your View is Windows Forms, ASP, whatever, all it needs to understand is how to render the domain-meaningless interface.
@D: “Correct” HTML is view independent.
It should “Model” the document text and structure of the document (e.g. this is a top-level heading, this is a sub-heading, this is a paragraph, emphasise this text, etc) but should not dictate how the document is actually presented (e.g. big bold Times heading, 10pt gap after each paragraph) as that is the job of the CSS “View”.
That is why elements like FONT, I, and B are deprecated in modern HTML and is why people get worked up about “tables for layout”.
As both of these break the model pattern.
Stop sweating it!
MVC is simply a label on what good programmers have been doing for decades. All it states is that your data (including how you read and write your data) is separate from your logic, and how you display the results is separate from the rest of your code. That’s it. Nothing more to it.
For example, let’s say you have a program that reads data from a database and produces a text report. Something a bit more complex than simple SQL statements. Now, imagine what would happen if your data source was changed. What if the database was completely refactored? How much of your program would you have to change? If you kept your data (model) separate from your business logic (code), the damage would be very limited.
What if you were told that you’d now have to produce not just the report, but an XML file? Again, if your output (view) was separate from your logic and data, generating the XML output should be very straight forward.
The only real difference is that there are dozens of MVC frameworks out there. I always suggest that people take a quick look at Rails to understand MVC. With in 30 minutes of reviewing the web tutorial, you’ll get an excellent understanding how a good framework can help you write MVC style development.
From a desktop application point of view I’d rather group html+css as the model, the rendering engine (gecko i.e.) the view and the navigator (user input, javascript interpreter, etc…) as the controller.
I personally never quite understood the difference between the controller and view. The view has to create buttons and stuff that the controller needs to update the model so how can those be separate?
Would be a nice post, if you hadn’t misunderstood (or misrepresented) MVC. It has nothing to do with whether your application is skinnable (or “skinnable”) - I’m pretty sure most skinnable applications don’t use MVC correctly - and the HTML-CSS-Browser example is, as “experienced architecture astronaut” wrote, certainly not MVC. Perhaps the case could be made that HTML is the model, but CSS the view? That’s where your analogy jumped the shark.
Now, I’m not currently a .NET developer, but a ColdFusion one, and have been looking at ASP.NET MVC with great interest only this morning. In the CF world, nearly every framework out there is MVC and it’s what I’ve been used to for around eight years or so. So much, in fact, that the traditional idea of one aspx file per page seemed a little backward - which previously put me off ASP.NET
ASP.NET MVC is definitely a step in the right direction, and the implementation seems nice and clean and simple - I will definitely be taking a closer look at ASP.NET now.
I think that I understand MVC, but my problem with MVC (and all patterns in general) is that I don’t understand how to implement them. I want to learn how to do things myself without using frameworks so that I can fully understand how they work.
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.
Jeff,
Interesting analogy, and quite a bit different from the one I usually use. In my mind, the View is the interface between the app and the user, the Model is the interface between the app and its data (web services, DB, whatever), and the Controller is the traffic cop. I would also take the middle part of that analogy 1 step further to say that if you’re accessing your back end from anywhere other than a Model, you’ve broken the pattern.
“only the controller is responsible for poking the model data through the … view”? But I thought that the view had to ask questions and send messages. It has to speak the language of the model. If that’s so, then the controller should make introductions and get out of the way. What you just described is Model View Presenter.
@Daniel Lehman:
Think of it this way: the buttons are generic ways to update the model. Imagine, instead, there is only one field. When you type into that field, the field sends that data to the controller. The controller should be separated from the views, in that the controller can take any set of valid data, no matter how its inputted, from a file, from the user, or just plain random dice rolls, and do something with it; be that call a view with the data, or update the database. If you cannot send data to your controller via any set of methods, ie a file vs a form, then its not separated well enough.
“Also in the case of web apps, we cannot seperate logic from presentation completely.”
This is not true. There exist a large number of JavaScript application frameworks (for example, Ext at http://extjs.com) which let you build apps using JavaScript, and relying on AJAX for data calls. A company I worked at previously serialized the data from the DB into XML/JSON, which was then loaded by the client and used to populate views.
In this sense, JavaScript is powering the Model (data storage and transport), the View (UI components being generated from DOM elements, and not HTML), and the Controller, and the backend is being used as a glorified database gateway (obviously with some security and data sanity checks). This frees up server resources, because we can put a significant amount of processing onto the client. It also means we could write web apps like desktop MVC applications.
To me, this class of web applications is far more interesting and fun to write.
Those descriptions of MVC were sort of fascinating in terms of language used- The same way you’ll notice people whose first language isn’t english refer to “codes” instead of code, I noticed that the description completely flipped user input / user output, relative to the way I’m used to hearing them (Not claiming anyone is right/wrong, just noticing the differences in how it’s used)-
He used “User Output” to describe data going FROM the user TO the machine (which would be output from the user) I tend to hear “User Input” used that way… Ditto his use of “User Input” to mean graphs presented to the user.