hellorobot.org

The MVC pattern in is hard to paraphrase in a single sentence – harder than I realize. The final sentence of the pattern’s introductory Wikipedia paragraph states that “[t]he model-view-controller … decoupl[es] data access and business logic from data presentation and user interaction, by introducing an intermediate component: the controller.”

I’m quibbling over language semantics, but since this is a fairly common boilerplate description of the pattern, it’s led me astray. On reading definitions like this I had come to an understanding of the MVC as a linear relationship between two components, Model and View, with a mediator between, the controller. I mean that I misunderstood the pattern to be such that the Model and View never directly communicate – that the controller would handle all communication between the two ends.

Wikipedia does describe the pattern further and discuss, albeit briefly, ways in which the model and view would communicate. It also includes a visual aid depicting the relationship between the three parts.

“MVC helps to reduce the complexity in architectural design, and to increase flexibility and reuse.” In a web application, the model is the most static element across time; the data behind a website may change but the shape of the data, the organization of the data, if well constructed, is fairly stable. The physical appearance and degree of interactivity of the site’s actual web pages – this will change the most: adapting to new delivery formats (iPhone, text readers, etc.) as well as adjusting regularly to design trends and new technologies (consider the way AJAX changed the possibilities of front-end development).

Creating a consistent, encapsulated layer around the data, one that’s easy to maintain, is good. It’s extending the lifetime of that data structure, creating the ability to apply it to multiple view types and demands. It makes sense then that the model is blind to the view. And if the controller were always the intermediary between the two, the controller would be too tightly coupled to each: any real change to the view would require one to the controller as well. That’s where my first interpretation of MVC went awry. What was the point of having three components? That’s what didn’t make sense. The controller was basically an extension of the view.

At ootips.org, there’s this helpful description of the interaction between the components:

[T]he model points to the viewport, which allows it to send the viewport weakly-typed notifications of change. Of course, the model’s viewport pointer is only a base class pointer; the model should know nothing about the kind of viewports which observe it. By contrast, the viewport knows exactly what kind of model it observes. The viewport also has a strongly-typed pointer to the model, allowing it to call any of the model’s functions. In addition, the viewport also has a pointer to the controller, but it should not call functions in the controller aside from those defined in the base class. The reason is you may want to swap out one controller for another, so you’ll need to keep the dependencies minimal. The controller has pointers to both the model and the viewport and knows the type of both. Since the controller defines the behavior of the triad, it must know the type of both the model and the viewport in order to translate user input into application response.

Frankly I’m still murky on the whole set up, and expect to stumble about plenty as I try to implement it for the first time. I’d love to find more samples online, especially good ones using the Zend Framework. But having a clear sense of what each component should “know” about the others, and keeping a hard line on dependencies, I think these will be helpful concepts to begin experimenting and learning-through-doing.