MVC (Model, View, Controller) is a pattern for organising code in an application to improve maintainability.
Imagine a photographer with his camera in a studio. A customer asks him to take a photo of a box.
Non-MVC architectures tend to be tightly integrated together. If the box, the controller and the camera were one-and-the-same-object then, we would have to pull apart and then re-build both the box and the camera each time we wanted to get a new view. Also, taking the photo would always be like trying to take a selfie - and that's not always very easy.
The author refers to mvctree.py in wxPython as an example of MVC design.
However I'm still too green so I find that particular example too complex
and I'm not understanding the separation the author is recommending.
MVC is all about separation of concerns.
The Model is responsible for managing the program's data (both private
and client data). The View/Controller is responsible for providing the
outside world with the means to interact with the program's client
The Model provides an internal interface (API) to enable other parts
of the program to interact with it. The View/Controller provides an
external interface (GUI/CLI/web form/high-level IPC/etc.) to enable
everything outwith the program to communicate with it.
The Model is responsible for maintaining the integrity of the
program's data, because if that gets corrupted then it's game over for
everyone. The View/Controller is responsible for maintaining the
integrity of the UI, making sure all text views are displaying
up-to-date values, disabling menu items that don't apply to the
current focus, etc.
The Model contains no View/Controller code; no GUI widget classes, no
code for laying out dialog boxes or receiving user input. The
View/Controller contains no Model code; no code for validating URLs or
performing SQL queries, and no original state either: any data held by
widgets is for display purposes only, and merely a reflection of the
true data stored in the Model.
Now, here's the test of a true MVC design: the program should in
essence be fully functional even without a View/Controller attached.
OK, the outside world will have trouble interacting with it in that
form, but as long as one knows the appropriate Model API incantations,
the program will hold and manipulate data as normal.
Why is this possible? Well, the simple answer is that it's all thanks
to the low coupling between the Model and View/Controller layers.
However, this isn't the full story. What's key to the whole MVC
pattern is the direction in which those connection goes: ALL
instructions flow from the View/Controller to the Model. The Model
NEVER tells the View/Controller what to do.
Why? Because in MVC, while the View/Controller is permitted to know a
little about the Model (specifically, the Model's API), but the Model
is not allowed to know anything whatsoever about the View/Controller.
Why? Because MVC is about creating a clear separation of concerns.
Why? To help prevent program complexity spiralling out of control and
burying you, the developer, under it. The bigger the program, the
greater the number of components in that program. And the more
connections exist between those components, the harder it is for
developers to maintain/extend/replace individual components, or even
just follow how the whole system works. Ask yourself this: when
looking at a diagram of the program's structure, would you rather see
a tree or a cat's cradle? The MVC pattern avoids the latter by
disallowing circular connections: B can connect to A, but A cannot
connect to B. In this case, A is the Model and B is the
BTW, if you're sharp, you'll notice a problem with the 'one-way'
restriction just described: how can the Model inform the
View/Controller of changes in the Model's user data when the Model
isn't even allowed to know that the View/Controller, never mind send
messages to it? But don't worry: there is a solution to this, and it's
rather neat even if it does seem a bit roundabout at first. We'll get
back to that in a moment.
In practical terms, then, a View/Controller object may, via the
Model's API, 1. tell the Model to do things (execute commands), and 2.
tell the Model to give it things (return data). The View/Controller
pushes instructions to the Model layer and pulls information from the Model layer.
And that's where your first MyCoolListControl example goes wrong,
because the API for that class requires that information be pushed
into it, so you're back to having a two-way coupling between layers,
violating the MVC rules and dumping you right back into the cat's
cradle architecture that you were [presumably] trying to avoid in the
Instead, the MyCoolListControl class should go with the flow, pulling
the data it needs from the layer below, when it needs it. In the case
of a list widget, that generally means asking how many values there
are and then asking for each of those items in turn, because that's
about the simplest and loosest way to do it and therefore keeps what
coupling there is to a minimum. And if the widget wants, say, to
present those values to the user in nice alphabetical order then
that's its perogative; and its responsibility, of course.
Now, one last conundrum, as I hinted at earlier: how do you keep the
UI's display synchronised with the Model's state in an MVC-based
Here's the problem: many View objects are stateful, e.g. a checkbox
may be ticked or unticked, a text field may contain some editable
text. However, MVC dictates that all user data be stored in the Model
layer, so any data held by other layers for display purposes (the
checkbox's state, the text field's current text) must therefore be a
subsidiary copy of that primary Model data. But if the Model's state
changes, the View's copy of that state will no longer be accurate and
needs to be refreshed.
But how? The MVC pattern prevents the Model pushing a fresh copy of
that information into the View layer. Heck, it doesn't even allow the
Model to send the View a message to say its state has changed.
Well, almost. Okay, the Model layer isn't allowed to talk directly to
other layers, since to do so would require it knows something about
those layers, and MVC rules prevent that. However, if a tree falls in
a forest and nobody's around to hear it, does it make a sound?
The answer, you see, is to set up a notifications system, providing
the Model layer with a place it can announce to no-one in particular
that it has just done something interesting. Other layers can then
post listeners with that notification system to listen for those
announcements that they're actually interested in. The Model layer
doesn't need to know anything about who's listening (or even if anyone
is listening at all!); it just posts an announcement and then forgets
about it. And if anyone hears that announcement and feels like doing
something afterwards - like asking the Model for some new data so it
can update its on-screen display - then great. The Model just lists
what notifications it sends as part of its API definition; and what
anyone else does with that knowledge is up to them.
MVC is preserved, and everyone is happy. Your application framework
may well provide a built-in notifications system, or you can write
your own if not (see the 'observer pattern').
Anyway, hope that helps. Once you understand the motivations behind
MVC, the reasons why things are done the way they are starts to make
sense, even when - at first glance - they seem more complex than