Confusion over definition of Controller in MVC

I've got a frustrated anonymous poster who complains that my definition of ViewModel in Model/View/ViewModel is exactly that of Controller in MVC, and references Cocoa.

It appears to me that Cocoa has changed the definition of Controller from the original 1979 Smalltalk term.  In that framework, the Controller was responsible for mapping Input to the Model and the View. 

But according to the Cocoa definition I found on Apple's site:

"A controller object acts as the intermediary between the application’s view objects and its model objects."

It appears Cocoa also recommends dividing the Controller into a model-controller and a view-controller, and if I read between the lines correctly, the view-controller is where view state would go.  I like this pattern rather a lot, but it is different from the MVC I have been contrasting with.

As an aside, I found a third way of looking at MVC in a old Java article: .  Notice how the diagram shows Model in the middle, with View and Controller only talking through the Model. 

Comments (8)

  1. Some Guy says:

    Looks like you didn’t understand my complaint, either. I did not say that your half-baked "view model" notion was the same as the ST-80 concept of a controller.

    You’re reinventing the wheel, and you’re still at the three-sided polygon stage. Maybe you can make it good enough for people who are used to tolerating abortions like C++ and Java if you add a dozen more sides or so. Good luck with that.

    Newsflash! MS announces wheel! ("Roundness" feature deferred from longhorn)

    Oh, and to correct your misunderstandings of Cocoa, try picking up Aaron Hillegass’s excellent book if you’re unable to figure it out from Apple’s documentation.

  2. Alan Stevens says:

    Wouldn’t a view-controller be the same as Fowler’s presenter object in model view presenter?

  3. My recollection from the eighties is that the Controller was commonly believed not only to map input, but to determine how that input affected the model. So it might have state machines as well. Essentially it handled user interaction.

    This was after the original Smalltalk but during the diffusion of Parc ideas into many other graphics systems.

    I believe this is still the best definition, as far as code organization, if you want to go that route.

  4. I think that maybe an example of the Model/View/ModelView pattern would make things clearer. Allthough I am the first to admit that it is not easy to provide a simple example for a non-trivial pattern.


  5. Another dude says:

    Seems to me that everyone has their own implementation of Model/View/Controller.

    John, let’s see an actual example, as Dirk here suggests. I think it must really be simple to provide an example. If not, you ain’t got a real pattern here.

  6. Actual dude says:

    Oh and by the way. As I see it, even your different references to Cocoa, Apple, SmallTalk and you ‘very own’ MVVC are all about the same thing: Model/View/Control, described from different perspectives.

    Try finding the pattern in all of these patterns. 😉

  7. JohnGossman says:

    I have always referred to MVVM as a variant or refinement of MVC, with specific reliance on data-binding.

    As these things tend to go, work has gotten busy. I need to post more about data-binding and commands, then give an example. I just haven’t had time.

  8. Dirk says:

    Take whatever time you need to provide us with a good example. If you need another week, then I’ll wait another week. If you need another month, then I’ll wait another month. As long as the example has the potential to spark another intense week 😉

Skip to main content