Understanding Model-View-Controller

Like everything else in software engineering, it seems, the concept of Model-View-Controller was originally invented by Smalltalk programmers.

This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/05/understanding-model-view-controller.html

While MVC is a good pattern, its worth taking the time to understand its more modern counterpart - MVP (model view presenter). In fact many so called MVC implementations are actually MVP.

There are many articles on this but the best in my opinion is the experience report of Andy Bower and Blari McGlashan at ESUG2000 (http://www.object-arts.com/papers/TwistingTheTriad.PDF)

The neat thing about this paper is that it actually gives a first hand account of exploring MVC and then discovering that MVP is more appropriate.

Even neater still is that you can actually see and use a very clean implemenation of MVP in Dolphin Smalltalk (yes the S word again). Get a copy of the free Dolphin and actually visually create a View, and then hook it up to a model with a presenter. Then realise that you can then use that new “triad” as a sub component - simply genius, and something that hasn’t had as much credit is it should have.


This is complete and utter hogwash. You start off by saying that the standard web is a great example of MVC. You INCORRECTLY state that HTML is the model and CSS is the view. Yet I can have pure HTML with no CSS at all (like in the old days) and still give the user a view into data sitting on the server.

You then go on to quote someone who corrects you stating that HTML is actually the view and the model is actually data and objects sitting on the server. I’m not sure that I am buying that either but it is at least much more paletable than your original stretch.

But then you go on to say that skinning has something to do with how well we’ve implemented the MVC pattern. Yet many apps exist that are supposedly skinnable that don’t follow the MVC pattern at all. It is true that if you follow the MVC pattern your app is more LIKELY to be easily skinnable. But just because your app is skinnable doesn’t mean that it is a good implementation of MVC.

If you’ve done one thing right it’s to show that the whole concept of what MVC actually means is open to a wide array of interpretations!

Applications interact with users and present data. The separation of interaction, presentation and data is one that comes fairly naturally to an experienced programmer - this doesn’t need to attribute itself to the idea of MVC though.

A problem with MVC is that it’s so generic it can apply to almost any architecture that isn’t total spaghetti code. This makes new programmers feel stupid since they will gain understanding of a particular flavour of MVC, and then run into a different flavour and think to themselves, “hmm, I guess I don’t understand MVC after all.” Eventually they realize that the term MVC is so broadly applied to that it doesn’t convey much information unless qualified with a particular flavour of MVC, e.g. “Smalltalk MVC” , “Cocoa MVC” or “Rails MVC”.

In web applications the term MVC is particularly meaningless and overused. Django was created without MVC in mind, but it’s a well designed framework, so it’s easy to say, “oh the views are the controllers and the templates are the views”. Rails Controllers have a render method and provide data to the Views, which goes against the Smalltalk MVC of “[the view] gets the data necessary for the presentation from the model by asking questions.” If Smalltalk MVC and Rails MVC are fairly different does this mean one is “wrong” and the other is “right”? No, of course not. But adherence to the idea of MVC encourages people to try and force everything into only three types of components. Do permissions get handled by the controller or the model? What about observers/subscribers? There are lots of parts in a web application that don’t fit cleanly into MVC. Anytime your application has heavy base classes or people recommend a “fat model” it probably means that you should have more than three types of holes to pound your code into …

Nice to see you blogging about code again, Jeff.

Another big problem with MVC is when two MVC frameworks collide. Having a UI toolkit that also does MVC means, in Java Swing for example, mapping your UI control’s data model to your application’s data model. Add a binding framework or an ORM, and you’ve got model-to-model translation code coming out of your ears.


Thanks for the explanation. But in Trygve’s definition for view I read: “It may also update the model by sending appropriate messages”. So when would you update the model directly from the view and when using the controller?

Can you think of any situations in which MVC might speciously appear to be a good solution, but would actually make things more difficult or less maintainable?

Sounds like there is disagreement and misunderstanding :slight_smile: I don’t claim to offer the “correct” answer, but I will define how I have been applying MVC to good effect lately.

Model – Data only. Get methods, set methods, etc. It is isolated – it knows nothing about the View, nor the Controller.

View – UI only. Dumb or “humble”. Only shows what you tell it to, and never performs any transformation or validation logic – e.g., it always forwards input via an event/callback system. It is isolated - it knows nothing about the Model, nor the Controller.

Controller – Sits between Model and View. Does any data transformation (business logic) that is necessary to get the data from the Model to the View. Does most data validation on input that comes back from the View. It “knows” about both the View and the Model.

With this definition it becomes much easier to divvy up work between engineers. If someone is a database engineer, they probably don’t know UI. But they can write the Model to great effect, and hey maybe they can stub out a crappy-and-simple View. Maybe it’s simply a text dump of the data, that’s fine. At least the code-level interface is in place. Then the UI developers can come and write the Controller and View. Then when the UX designers change what they want the UI to look like, you can either change the View or write a new one. Or if you want to use different UI technologies – WinForms on XP, WPF on Vista, or Cocoa on MacOS, then just have different View implementations for each. Things like skinning are then easily isolated to the View pillar.

The other useful pattern to employ here is an Inversion of Control (IoC) container/scope object. None of the classes participating in MVC need to know about the specific implementation of each other, just the interface/contract. This makes it trivial to unit test the Controller with faked out View and Model implementations. The Controller just says, “hey Create me an instance of I____View” … and your unit test harness just happens to be providing it the Mock____View instead of the ____View that is used in production.

Seems a stretch to consider a browser a controller. Typically a controller can modify the model. A browser typically isn’t used to modify the HTML it receives.

If you’re using a modern IDE (such as Delphi, VB, or C#) then you must understand the little-known ‘Document-View’ pattern in order to properly evaluate MVC. Most IDEs implement the Controller for you, meaning that implementing it again is counterproductive.

Jeff, if the view is “a (visual) representation of its model” then I think CSS wouldn’t be the view in your example because it determines HOW your model will be represented and not what your model represents. I am wrong?

Very informative post for a university student who is taking a web authoring unit next semester. Thanks for shedding light on the MVC model, will definitely read more about it and implement it from start.

You then go on to quote someone who corrects you stating that HTML is actually the view and the model is actually data and objects sitting on the server. I’m not sure that I am buying that either but it is at least much more paletable than your original stretch.

There are two different examples of MVC presented in the above article:

  1. Web content
  2. Three-tier web development

I believe both are completely valid examples of MVC.

The web content example may be a distraction for hardcore software developers, but I believe it is an excellent (and completely valid!) illustration of the benefits of MVC to a layperson or casual programmer.

I think CSS wouldn’t be the view in your example because it determines HOW your model will be represented and not what your model represents

I don’t understand this criticism. Here’s what Trygve defines a View as doing:

"A view is a (visual) representation of its model. It would ordinarily highlight certain attributes of the model and suppress others. It is thus acting as a presentation filter. "

Isn’t CSS used to do exactly this on the underlying HTML?

  • make this bold
  • increase the size of this
  • move this DIV over here
  • hide this content
  • place this background image here

It’s the very definition of a “presentation filter”, ala CSS Zen Garden. http://www.codinghorror.com/blog/archives/000474.html

The only problem with MVC is that for very small apps, its kind of a big overhead.
Also in the case of web apps, we cannot seperate logic from presentation completely.

in the case of web apps, we cannot seperate logic from presentation completely.

You can also see this with HTML+CSS ; having a totally skinnable set of HTML means constructing the HTML markup with CSS design in mind. For example, you shouldn’t use IMG tags but instead replaceable DIVs…

I made a couple sites with struts like 3 years ago. It really forces the MVC pattern. There’s a good description on their homepage.


You should see what else Trygve Reenskaug has been up to. He’s still workin in Norway and he has some interesting ideas about how to go beyond MVC.

Moving from the traditional ASP.Net model to ASP.NET MVC Framework definitely helped my four-month old, facebook-app/dev startup tremendously. It’s fantastic. I highly recommned it. Though not a silver bullet, it definitely allowed my friend and I work to more effectively. I’m really glad you took time to shine some light on this topic. :slight_smile: