The description MVC describes a particular way of building applications which incorporate graphical user-interfaces. These days we are all familiar with windows, icons, push-buttons and so on—all driven by a mouse or some other pointing device. However when Smalltalk was created, such interfaces were only just being invented.
Smalltalk's designers had to come up with a way of implementing a graphical user-interface in a way which would be extendable. MVC is what they came up with.
The basic premise behind the MVC architecture is that the user-interface of an application should be separated from the application functionality itself. Sometimes this is done in conventional (non-object-oriented) programs and sometimes it is not. Some object-oriented programs don't do it either, but it's not difficult to see the justification for advocating this separation.
Separating the application from its UI allows them to be developed separately. More importantly, it allows a new and different UI to be easily connected to an existing application. It also allows components of an existing UI to be reused on a new application. Finally, it allows an application to be used without its UI, perhaps by another application.
The diagram below shows these options. You can see that all these justifications are related to the modularity, reusability and encapsulation which object-orientation promotes.
By separating the application logic from the Uf, an application can have several user -interfaces, or none.
The MVC Architecture
In Smalltalk, this separation of an application into its functionality and its user-interface is accomplished by using separate objects to implement the two parts. The most important objects on the application functionality side are referred to as models. They are the M in MVC.
The most important objects on the user-interface side are referred to as views and controllers. They are the V and the C in MVC.
The class library actually provides three classes called Model, view and Controller . Most objects which are behaving as models, views, or controllers (and we'll see what that means shortly), inherit from one of these base classes. This isn't always the case though, especially for models, so don't let that confuse you. What's important in MVC is whether an object is behaving like a model or a view or a controller, not whether it necessarily inherits from Model, view, or Controller. Of course, every Smalltalk program also contains lots of objects which aren't models, views, or controllers. Don't get the impression these are not important—they are, it's just that they're not the subject of this chapter!
The MVC Architecture
The MVC architecture divides an application up into objects we can think about as being of three types: models, views and controllers. Let's start by taking a look at what each of these kinds of object are for, and how they interact with the other kinds.
Models
Models implement application functionality. They are responsible for holding the data which is relevant to the application, and acting upon it in the ways the application defines. They can be very simple (for example, an instance of class String can be a model), or very complex (perhaps an entire word processing application). Very often, several model objects will work together to implement the application, and we'll see a particular way of arranging this later.
What matters is that models hold the data, and act upon it in ways which are independent of the interface. This allows different user-interfaces, or other objects, to use the model functionality. You can start to see a similarity to the naivety we talked about when discussing the dependency mechanism.
Views
Views present information to the user. They are responsible for taking the data held in model objects and displaying it on the screen in the form of text, graphics, widgets and so on. However, views don't 'understand' the data. Neither do they act upon it, except in the ways necessary to display it.
The class library provides all sorts of different views. These allow you to display the data in your models in all sorts of different ways, without having to change the models. You will find that there are views for everything, from whole windows to scrollbar buttons. A single window almost always contains many view objects cooperating together to create the user-interface.
Controllers
Views are responsible for the output, or display side of the user-interface. Controllers on the other hand, are responsible for handling input. They 'listen' to the keyboard and mouse, and interpret input from both in terms of how the model must be manipulated. Again, the system class library contains many different controller classes. Each one of these controllers is usually specialised to work with one or more types of view. Controllers are always paired up with views, but they tend to be the 'poor relation' of the two. Wherever there's a view though, there's usually a controller lurking in the background.
Putting MVC Together
You should now have a basic idea of how the models, views and controllers in an application work together to implement the application's functionality, present it to the user and allow the user to interact with the application. As the next diagram shows, models, views and controllers tend to form little 'triads' of co-operating objects. Each model object is interfaced to the screen, keyboard and mouse by a view object and a controller object.
Sadly, the partitioning of functionality among models, views and controllers, is not an exact science. Sometimes, 'view-like' functionality leaks into models when they have to know something about exactly how they're being presented on the screen. At other times, 'model-like' functionality leaks into controllers, where it is more convenient to deal with mouse-clicks and so on. Don't worry too much about this. The important thing when designing a system, and deciding
The MVC Architecture
The views and controllers work together to control the user-interface to the models.
what to put where, is to try to remember why functionality should be split the way it is. Keeping in mind the normal OOP goals of modularity, reusability and encapsulation should help you to make the right decisions.