What is a Model ViewController system

An MVC system has three subsystems. The Model contains what is often called business logic, or all the data and information manipulated by your system. The View contains the objects that display the data, and the Controller manages the interaction with the user and mediates between the Model and the View. Table 5.3 summarizes the components.

Table 5.3 The components of standard MVC architecture

Component

Description

Model

Business logic. Contains all the data manipulated by the system. This can include an interface to an external store, such as a database. Typically the model exposes only a public API to the other components.

View

Display code. The widgets that actually place the information in the user's view. In wxPython, pretty much anything in the wx.window hierarchy is part of the view subsystem.

Controller

Interaction logic. The code that receives user events and ensures that they are handled by the system. In wxPython, this subsystem is represented by the wx.EvtHandler hierarchy.

In many modern UI toolkits, the View and Controller components are somewhat intertangled. This is because the Controller components themselves need to be displayed on the screen, and because often you want widgets that display data to also respond to user events. In wxPython, this relationship is enshrined by the fact that all wx.Window objects are also subclasses of wx.EvtHandler, meaning they function as both View elements and Controller elements. In contrast, most web-application frameworks have a stricter separation between View and Controller, since the interaction logic happens behind the scenes on the server.

Figure 5.2 shows one rendering of how data and information is passed in an MVC architecture.

An event notification is handled by the Controller system, which dispatches it to the appropriate place. As we saw in chapter 3, wxPython manages this mechanism using the wx.EvtHandler method ProcessEvent(). In a strict MVC design, your handler functions might actually be declared in a separate controller object, rather than in the frame class itself.

In response to the event, the model objects can do some processing on the application data. When that processing is done, the model sends an update notification. If there is a controller object, the notification is usually sent back to the controller and the controller notifies the appropriate view objects to update themselves. In a smaller system or a simpler architecture, the notification is often directly received by the view objects. In wxPython, the exact nature of the update from the model is up to you. Options include explicitly raising custom wxPython events from the model or controller, having the model maintain a list of objects that receive update notifications, or having views register themselves with the model.

Figure 5.2 The data flow of an MVC request

The key to a successful MVC design is not in making sure that every object knows about every other object. Instead, a successful MVC program explicitly hides knowledge about one part of the program from the other parts. The goal is for the systems to interact minimally, and over a well-defined set of methods. In particular, the Model component should be completely isolated from the View and Controller. You should be able to make arbitrary changes to either of those systems without changing your Model classes. Ideally, you'd even be able to use the same Model classes to drive non-wxPython interfaces, but that would preclude, say, using wxPython events for update notification.

From the View side, you should be able to make arbitrary changes in the implementation of the Model objects without changing the View or the Controller. While the View will depend on the existence of certain public methods, it should never get to see the private internals of the Model. Admittedly, this is difficult to enforce in Python, but one way to help enforcement it is to create an abstract Model class that defines the API that the View can see. Subclasses of the Model can either act as proxies for an internal class that can be changed, or can simply contain the internal workings themselves. The first option is more structured, the second is easier to implement.

In the next section, we'll take a look at one of the Model classes built into wxPython, wx.grid.PyGridTableBase. This class makes it possible to use a grid control within an MVC design framework. After that, we'll take a look at building and using a custom model class for a custom widget.

Was this article helpful?

0 -1

Post a comment