Section 3.1. What Is MVC?

3.1. What Is MVC?

Let's start out with a high-level overview of the MVC architecture. Don't worry if this makes your head hurtwe explain in more detail in the next few pages.

1. The models represent various pieces of domain data, such as a person's name, or the total sales for the day so far at your local Victoria's Secret branch, or the current status of your build tests.

2. The views present that data to the user in some way. They might display a list of users on a web page, show a running sales total on an LED display, or power on a red lava lamp when the builds fail.

3. Controllers listen for input (actions), provide the logic necessary to parse those actions, send update requests to the model, and sometimes invoke new views for display.

One benefit of MVC is that it helps you keep different parts of your application separated and isolate potential changes to one area of your code.

So, to bring it all together, suppose you've hacked together an automated build system for the team of developers you are getting together to work on your new Ajax-enabled web 2.0 start-up that you think is going to revolutionize the way we buy organically grown toe lint on the Internet.

If you use MVC for this automated build system, when you check in your code and one of your unit tests fails, the automated build test program will send a message to your application's controller object.

Purity, Pragmatism, MVC, and the Web

Before we lose all 11 of you who actually remember MVC from Smalltalk-80, we thought we'd mention that this isn't the way the original MVC worked. Back then, controllers listened for key presses and mouse clicks, and then interpreted those things and sent messages over to the model to change its state. Every view object was responsible for paying attention to the model and updating itself whenever there was a change.

In the meantime, WebObjects, Struts, and Cocoa have redefined MVC to include a tighter relationship between view and controllers. In a way, this was inevitable because modern window managers and web programming have abstracted away most of the "user event interpretation," which used to be the controller's main job. There's plenty of room to move some view functionality over into the controller, which helps keep views simple enough that designers have a fighting chance to be able to edit views on their own.

So, nearly all modern MVC-based web frameworks use the controller as a place to put some of the glue code and to provide (at least potentially) a layer of abstraction between models and views.

The controller object in turn publishes that information to the model, which changes its state to Tests="Failing."

Meanwhile, you have a view class that's polling the model regularly to see whether it has changed, and when it does, it starts playing an endless loop of Homer Simpson saying "D'oh!" (at least until somebody fixes that darned failing test). That, in turn, sends a message to the controller, which updates the model, at which point the view sees that the model has changed so that the tests are no longer failing and stops playing that annoying MP3.