2.5.1 Model-View-Adapter (MVA, Mediated MVC, Model-Mediator-View)

Motivation

Model-View-Adapter is a variation of the Triad where all communication between Model and View must flow through a Controller, instead of interacting directly as in a Traditional MVC Triad. The Controller becomes a communication hub, accepting change notifications from Model objects and UI events from the View.

This approach might appear excessively strict, but has some advantages: the communication network is artificially constrained, making it easier to evaluate and debug. All action happens in the Controller, and the View can be created from off-the-shelf widgets without any Model-specific variation.

Design

MVA is an implementation of the Mediator pattern. Controllers are generally referred as Adapters or Mediators. The Model and the View do not hold references to each other, they do not exchange data nor interact directly.

The pattern of communication in MVA can be represented with the following interaction diagram

which can be described as

1. The View receives a UI event. It calls an appropriate method on the Controller.
2. The Controller sets the value on the Model.
3. The Model notifies its listeners of the change, among which is the Controller itself. As already pointed out, in a MVC approach this notification would be sent to the View.
4. The notified Controller fetches information from the Model and updates the View.

With the Controller in full control on the dialog between the two remaining parties, smart tricks can be performed on the “in transit” data: for example, the Controller could be responsible for formatting, translating or ordering the data from the Model.

Practical Example 1: With Subclassing of the Views

common in Apple OSX Cocoa Framework.

We examine a MVA implementation of the Engine example in two steps. In the first step, we will keep subclassing the Views, to present the general concept. In the second step, we will remove the need for subclassing the Views.

The Model is unchanged: it stores rotations per minute information and notifies about changes

class Engine(BaseModel):
   def __init__(self):
       super(Engine, self).__init__()
       self._rpm = 0

   def setRpm(self, rpm):
       if rpm < 0:
           raise ValueError("Invalid rpm value")

       if rpm != self._rpm:
           self._rpm = rpm
           self._notifyListeners()

   def rpm(self):
       return self._rpm

The two View classes, Dial and Slider, are now unaware of the Model. Instead, they know about the Controller, and accept changes to their content through the setRpmValue() method. A matter of taste can decide the semantic level of this method. Should it talk “domain language” (i.e. Rpm) or not (i.e. the method should just be named setValue). In any case, Views behave differently with respect to the issued value (the Slider needs its value scaled appropriately). One could handle this difference in the Controller, but this will be considered in the next step.

When the user interacts with the Dial, the Controller changeRpm() method is directly invoked, in this case via the Qt Signal/Slot mechanism

class Dial(QtGui.QDial):
   def __init__(self, *args, **kwargs):
       super(Dial, self).__init__(*args, **kwargs)
       self._controller = None
       self.setRange(0, 10000)

   def setRpmValue(self, rpm_value):
       self.setValue(rpm_value)

   def setController(self, controller):
       self._controller = controller
       self.connect(self, QtCore.SIGNAL("valueChanged(int)"),
                          self._controller.changeRpm)

For the Slider, the interface is the same, but the internal implementation is different. Again, the setRpmValue allows the Controller to change the View contents. In this case however, a proper transformation of the data is performed to deal with the specifics of the Slider behavior, whose range is from 0 to 10. Similarly, when the User interact with the Slider, the method _valueChanged will be invoked, which in turn will issue a call to the Controller changeRpm() method, after transformation of the parameter

class Slider(QtGui.QSlider):
   def __init__(self, *args, **kwargs):
       super(Slider, self).__init__(*args, **kwargs)
       self._controller = None
       self.connect(self, QtCore.SIGNAL("valueChanged(int)"),
                          self._valueChanged)
       self.setRange(0,10)

   def setRpmValue(self, rpm_value):
       self.setValue(rpm_value/1000)

   def setController(self, controller):
       self._controller = controller

   def _valueChanged(self, value):
       if self._controller:
           self._controller.changeRpm(value*1000)

The Controller class handles the Model and the two Views accordingly. It registers for notifications on the Model, and it receives notification from the Views on its changeRpm() method, where it modifies the contents of the Model. When the Model communicates a change, it pushes the new value to the Views

class Controller(object):
   def __init__(self):
       self._views = []
       self._model = None

   def setModel(self, model):
       self._model = model
       model.register(self)

   def addView(self, view):
       view.setController(self)
       self._views.append(view)

   def changeRpm(self, rpm):
       if self._model:
           self._model.setRpm(rpm)

   def notify(self):
       for view in self._views:
           view.setRpmValue(self._model.rpm())

Practical Example 2: With generic Views

In the previous example, removing the dependency of the Views on the Model did not allow us to use generic Views. In this example we will move the value translation logic from the Views to the Controller, thus removing the need for subclassing the Views, an important advantage of MVA.

class Controller(object):
   def __init__(self, model, slider, dial):
       self._slider = slider
       self._dial = dial
       self.connect(self._slider, QtCore.SIGNAL("valueChanged(int)"),
                          self._sliderChanged)
       self.connect(self._dial, QtCore.SIGNAL("valueChanged(int)"),
                          self._dialChanged)
       self._model = model
       model.register(self)

   def changeRpm(self, rpm):
       if self._model:
           self._model.setRpm(rpm)

   def notify(self):
       for view in self._views:
           view.setRpmValue(self._model.rpm())

Practical Example 3: With forwarding of Model events

If the Model emits qualified events, the Controller could simply forward them to the View.