Compellingly Beautiful Software
Products Programming Contact
Steven T Abell, Software Designer, brising.com
Many software textbooks and articles mention the Model-View-Controller (MVC) UI architecture that originated in the Smalltalk programming language. Some of these claim to tell you what MVC means and how to build it. But, unless the book or article is explicitly about Smalltalk, and in some cases even if it is, what you're reading about probably isn't MVC.
MVC is an important milestone in object programming. It deals with three important abstract notions about objects: factoring, patterns, and frameworks.
Factoring means breaking your design into separate pieces, each of which is highly focused on some simpler thing or process, then reassembling the larger functionality from the smaller pieces. Good factoring can have several nice results, such as code reuse and improved maintainability.
Patterns are arrangements of objects that have the same general connective shape and channels of message flow. Knowledge of patterns can help you solve new problems in familiar ways. Even if you can't reuse existing code, you'll at least know how to go about what you're building.
When you factor a problem well, and then discover that you're building that same pattern over and over, sometimes you can build a framework, which is a partially-complete arrangement of objects. Frameworks help you get to the end of the job because you're starting from the middle of the job instead of from the beginning.
In Smalltalk, MVC became a framework and acquired many admirers, many of whom didn't really understand it. MVC breaks UI architecture into three pieces: Model, View, and Controller.
A Model is an object that (usually) holds data and (often) simulates a process. Properly-designed Models try not to make assumptions about how they will be displayed. They live in the dark depths of a computer, relying on other objects to expose them to a user. Although they don't contain any UI components, they often notify these components of internal changes in a very general way. In Java, these notification mechanisms are provided in classes such as Observable and PropertyChangeSupport, although I have to say that the implementation and performance of these particular foundation classes is execrable.
A View is an output device. Please reread the previous sentence until you understand just how definite and general that statement is. In the Graphical User Interfaces that have become so common, a View is usually thought of more specifically as a screen widget, such as a textfield.
A Controller is an input translator. Please reread the previous sentence until you understand just how definite and general that statement is. In today's GUIs, they are usually thought of more specifically as mouse and keyboard drivers.
Most widget kits, for example, AWT and Swing in Java, or Qt and the Microsoft widgets in C++, conflate the View and Controller into a single object. This is not really wrong, but it does limit some of the options in GUI construction. Because few people have ever seen true MVC, where Vs and Cs are created separately and then hooked together, few people understand the loss in VC conflation, but they still like to talk about MVC and how great it is. Maybe it makes them feel cool.
In the remainder of this article, a conflated View-Controller pair is referred to as a ViewControl.
So what do people mean when they talk about MVC? Good question, whose answer is sometimes "Your guess is as good as mine." When some people talk about a Controller, what they mean would be a very reasonable use of the word if the word was not already used elsewhere. This other object (the reasonable one) coordinates the interactions of the Model and one or more ViewControls. Various people have come up with various names for this object other than Controller. This is a good idea. I call it a Coordinator. Look over the alternatives you find in the literature, and by the end of the day I'll bet you'll call it a Coordinator, too.
How can you tell a Model-View-Controller from a Model-Coordinator-ViewControl? An MVC diagram is a triangle; an MCV diagram is linear (the degenerate case) or Y-shaped (the more general case, with possibly many branches in the Y). In MCV, the Coordinator sits between a Model and one or more ViewControls. The nature of the interactions is very different.
So if you read about MVC in the Swing documentation or some article on Java, let me suggest that you not take it very seriously. Swing is a decent-but-not-great piece of work, and it is not at all clear that its designers understood MVC very well. And if some professor gives you an assignment to build an MVC application in Java, you might send him an anonymous email suggesting that he read this page first. True MVC is out of reach for Java programmers who are building with the standard Swing or AWT widgets.
© 2002 brising.com