7. Coupling and the Model-View-Controller (MVC) Architecture¶

7.2.1. Version 1: Naively Mixing Control with The View¶

This is a naive Visual-Studio-style implementation, where the controller code is coded inside the private void button_Click(object sender, EventArgs e) method, which sits in the InputViewForm class, which itself owns all the system’s components:

The relevant code for this diagram reads like this:

 public partial class InputViewForm : Form  {
   private Model model = new Model();
   private OutputViewForm form = new OutputViewForm();

   public InputViewForm() { InitializeComponent(); }

   private void onButton_Click(object sender, EventArgs e) {
     //...
     model.update();
     out_form.update();
   }
 }

static class Program {
  static void Main() {
    Application.EnableVisualStyles();
    Application.SetCompatibleTextRenderingDefault(false);
    Application.Run(new InputViewForm());
  }
}

This is bad. It is bad because the entire system lives in the Form that handles input events. How can one team (typically the software engineers) develop the control and the model and another team (typically the graphical designers) develop the view, when all of these are mixed into one file?

Further, how can the components be extracted for reuse in future systems? And, why should a GUI with a button “own” the output form and also the system’s model (data base)? Will this architecture generalize to multiple forms where each form accepts input and shows output?

7.2.2. Measuring The Architecture’s Coupling¶

The above doesn’t sound good, and the problem is that there is “too much”/”too strong” coupling (dependency). There is a simple way to measure “degree of coupling” of a class-diagram assembly, A, in terms of A‘s sub-assemblies:

• Let N(A) is the number of classes in A. Define the number of sub-assemblies, S(A), as the number of subgraphs of A that contain at least one class and have no outgoing edges.

  (An edge in a subgraph is outgoing if it starts at a node in the subgraph and has an arrow to a node outside the subgraph.)

• Diagram A‘s coupling ratio, C(A), is the ratio of sub-assemblies per class: C(A) = S(A) / N(A).

The larger the value of C(A), the better — If there are more subassemblies per component, this means there are more possible ways of disassembling the system so that we can design, code, and test the system in stages. We can also find more ways of disassembling the system so that we can reuse its parts in other systems.

For the above architecture, V1, we have S(V1) = 3 and C(V1) = 3/3 = 1. That is, there are only 3 sub-assemblies (including the entire system) that we can extract and reuse out of this 3-component system. We can do better.

7.2.3. Version 2: Controller Separated from Views¶

We simply must untangle the controller code and model from the views: We extract the control code from the event-handler method (private void button_Click(object sender, EventArgs e)) in the input form and place it in its own class. Also, the model is not owned by any other assembly:

This is better. When you implement this architecture in Visual Studio, construct and connect the InputView, Controller, and Model objects in the Main method of Program.cs. (For the above, the OutputView is still constructed and owned by the InputView.) Here’s how to do it:

public partial class InputViewForm : Form  {
  private OutputViewForm out_form;
  private Model model;
  private Controller cont;

  public InputViewForm(Controller c, Model m) {
    InitializeComponent();  cont = c;  model = m;
    out_form = new OutputViewForm(model);
  }

  private void onButton_Click(object sender, EventArgs e) {
    cont.handle();  out_form.update();
  }
}

static class Program {
  public void Main() {  // construct and connect the components here:
    Model m = new Model();
    Controller c = new Controller(m);
    InputViewForm i = new InputViewForm(c, m);
    // ...
    Application.Run(i);  // give control to the input view
  }
}

Now, the Main method’s code documents the software architecture — you read it first to learn about the system. Also, this architecture makes it easier to extract sub-assemblies for coding, testing, and future reuse.

For this system, V2, we have S(V2) = 5 and C(V2) = 5/4 = 1.25, better than before.

It is still a (minor) problem that the input view owns and contacts the output view. Also, we would like to separate (decouple) the input view from the controller. This is because the input view (the “user interface”, the “GUI”) is often developed in a different language and in a different design tool than C#/Visual Studio.

Finally, modern GUI-based systems (like Visual Studio!), use multiple input views/forms and also multiple output views/form. We want a software architecture where it is easy to add and remove views, even while the system is executing. (Think about how windows appear and disappear when you run Visual Studio. What happens is more that just Showing and Hide-ing windows — windows are constructed, attached, used, removed, and deallocated.)

7.2.4. Version 3: Model-View-Controller¶

Now we study the first version of the Model-View-Controller (MVC) architecture. This version works well when there is just one controller object that handles all input events and does all model updates:

The key(s) are the delegate declarations. (Recall that a delegate is an “interface/data-type that specifies a single method.”)

• The input view depends on delegate inputHandler, which specifies the type of method that should be called when there is an input event.
• Delegate Observer specifies the type of method(s) that are called when the model is updated and the output view(s) should be called to repaint their displays. Each output view’s update method implements the Observer delegate, and it is register-ed with the controller, in the controller’s registry. (See the code just below.)

The remaining dependencies are:

• The controller depends on the model, because the controller’s purpose is to enforce the algorithm/protocol for calling the model’s methods.
• The output view depends on the model, because the output view’s purpose is to display a representation (a “view”!) of the model on the display. (If an output view/form is written in a language/tool different from C#/VS, we can insert a delegate declaration between the output view and the model.)

The Main method assembles the system and registers the Observer (s):

// the type of method that handles input events:
public delegate void InputHandler();
// the type of method that calls output views when there is a "model-update event":
public delegate void Observer();

static class Program {
  public void Main() {
    Model m = new Model();
    Controller c = new Controller(m);
    InputViewForm i = new InputViewForm(c.handle);  // recall that  c.handle  has type InputHandler
    OutputViewForm f = new OutputViewForm(m);
    f.Show();    // C# requires that you tell an output form to show itself
    c.register(f.update);   //  f.update  has type  Observer
    // ...
    Application.Run(i);
  }
}

When there is an input event, the InputViewForm‘s onButton_Click method (indirectly) calls handle in the controller, which executes the algorithm/protocol for the input event. The input view/form is not coupled to any controller or model. This makes it easy to develop the input view separately from the rest of the system.

When the controller does a model update, all methods saved in registry are called. So, the controller is not coupled to any view. This makes it easy to extend the system to have multiple forms (views) for inputs and outputs, like a spreadsheet or IDE does. It makes it easy for views to “come and go” while the system is executing. This is a standard technique in systems building, maybe the most important one you will learn in this course.

For this system, call it, V3, we have S(V3) = 9, and C(V3) = 9/4 = 2.25, which shows marked improvement.

An important variation on the above is to save the registry in the Model. Here is the revised sub-assembly:

This arrangement can be used when there are multiple input views, each of which contacts a distinct controller object to update the model. In such a situation, the registry cannot be saved in any one of the controllers, so we can save it with the model.

The previous arrangement is a bit less attractive because Model components (“data structures”) are rarely written with registries embedded in them. This flaw is repaired in Version 4, below.

Principles of MVC design

• Controllers are written to compute answers and to control/enforce the proper use of models (the “proper use” is the “protocol” or the “rules of the game”), so controllers are typically coupled to (depend on) the models they control.
• Output views are coupled to models, because the purpose of an output view is to display/pretty-print information embedded in a model. No component should be coupled to an output view.
• Models should not be coupled to any other assembly.
• If they are coupled to any other component, an input view/form is coupled to the controller that does the computation requested by the input event. No component should be coupled to an input view.

7.2.5. Version 4: Xerox PARC-style MVC with Sub-classing: Observer Design Pattern¶

Here is an improvement on the immediately previous architecture, where there are multiple controllers that update the model: We store the registry of observers in a super-class to which the model attaches:

Now, the model component extends (is a subclass of) an “observed model”, which is a class that holds the registry. This last pattern was the version of MVC developed by the Xerox PARC team. It is called the Observer design pattern. Here is the pattern of coding you can use:

public delegate void InputHandler(...);  // data type of input-event methods
public delegate void Observer();  // data type of output-refresh methods

public abstract class Observed Model {  // "abstract" means "unfinished"
  private List registry = new List();
  public void register(Observer x) { registry.Add(x); }
  public void notify() { foreach(Observer x in registry) { x(); } }
}

public class Model : ObservedModel {
  private Data mydata;
  // ...
  public void update(...) { mydata = ...; }
  public string getData() { ... return mydata; }
}

public class Control {
  private Model m;
  // ...
  public void handle(...) { m.update(...);  m.notify(); }
}

public class InputViewForm {
  private Button button1;
  private InputHandler han;
  // ...
  public void button1_Click(...) { han(...); }
}

public class OutputViewForm {
  private Label label1;
  private Model m;
  // ...
  public void repaint() { label1.Text = m.getData();  this.Refresh(); }
}

public class Program {
  public static void Main() {
    // ...
    Model model = new Model();
    Control c1 = new Control(model);
    InputViewForm f1 = new InputViewForm(c1.handle);
    Control c2 = new Control(model);
    InputViewForm f2 = new InputViewForm(c2.handle);
    OutputViewForm o1 = new OutputViewForm(model);
    model.register(o1.repaint);
    OutputViewForm o2 = new OutputViewForm(model);
    model.register(o2.repaint);
    f1.Show();  f2.Show();  o1.Show();  o2.Show();
    Application.Run();
  }
}

The subclass arrangement places the registry in a central place, at the model object, so that multiple forms and controllers can correctly share the model. Also, the observed model knows nothing about the class names of the forms that link to it — it is completely decoupled from the view assembly.

7.4.1. Model View Presenter: One View does input and simplistic output¶

For very simple reactive systems, where there is just one, simplistic view, we have this greatly simplified variant of MVC, called Model View Presenter. It has a linear topology and uses function call-return to do its work:

In&OutView           1. In&OutView calls Presenter with input event.
    |                2. Presenter computes answer, updates Model,
    V                   and queries Model for new values of data.
Presenter               Presenter returns the new data values as
    |                   the answer to the call in Step 1.
    V                3. In&OutView displays the returned answer.
  Model

The architecture places a burden on the Presenter component, which both implements the system’s algorithm and knows exactly the data that must be displayed. You will find this architecture in some business systems, e.g., an ATM connected to a bank or a calculator tool — the output view shows just a single number or a single string.

7.4.2. Model View Binder: Using an XML/HTML-based View¶

This architecture was developed by Microsoft (and called “Model View ViewModel”) to match their WFP and Silverlight system, but it resembles the layout used in many Enterprise Information Systems (EIS). It is a “web-browser-view plus model plus controller”:

Say we have a general-purpose output view, essentially a web-browser, that can show output formatted in some XML-like language. (XML is a “bracket language”; HTML is one instance of XML).

The controller not only signals the model to do updates, but it then fetches updated data from the model and formats it as an XML document. Then the output view fetches the XML document and displays it:

InView  OutView
  |         |
  V         V
Binder - ->delegate Observer
  |
  V
Model

The controller is called a “Binder”, because it does data bindings of the model’s data to names and layout in the XML document it builds:

1. The InView signals the Binder with an event.
2. The Binder updates the Model and queries the model for the new values of data.
3. The Binder organizes the new data into data bindings — a structure or “template” of how the data should be presented to the user. The template is coded as an XML document and held in the Binder.
4. The Binder signals, say, by delegate call, that all Observers should retrieve the template for presentation.
5. The Outview, which is registered as an Observer, retrieves the XML document and displays it.

Like the Presenter component, the Binder has multiple responsibilities. Unlike the Presenter, the Binder organizes in a semantically important way how the data must be viewed. Note that the Binder is not coupled to the OutView, so that the Binder and the Model can be designed and tested independently of the views.

When used for internet commerce, the InView and OutView are often merged together as a web browser or some XML/HTML-based viewer. The Binder is often a “proxy object” (we study this notion later) that was specially constructed by the Model and sent over the Web to the web browser to act as that browser’s personal Binder. The Binder contains the “business logic” for doing the commerce transactions.

Do not do this:

Perhaps the worst layout for a reactive system would be just one view/form that implements both input and output with this pattern of communication:

       In&OutView             1. View contacts Controller
       |        ^             2. Controller updates Model
       V        |             3. Model sends updated info to View
Controller --> Model

Beginners code reactive systems like this; there is only one subassembly of this “circular” system!

7.7.1. Measuring Cohesion¶

If you like numbers, here is a formula for calculating a numerical score of cohesion:

• Say that class D has F(D)-many fields and M(D)-many methods. Say that field f_i is referenced by m_i-many methods in D. Then, the cohesion of D, called H(D), is related to the number of times each of D‘s fields is referenced by D‘s methods:

  H(D) =  (m1 + m2 + ... + mM) / (F(D) * M(D))

H measures the percentage of fields required by each method. The maximal cohesion value is H(D) = 1 — every field is required by every method. For example, for this class:

public class Card {
  public readonly Count count;
  public readonly Suit suit;

  public Card(Count a, Suit b) { count = a;  suit = b; }

  public int BJvalue() {
    int i = (int)count + 1;
    if (i > 10) { i = 10; }   // in Blackjack, face cards have value 10
    return i;
  }

  public override string ToString() { return count + " of " + suit; }
}

H(Card) = (3 + 2)/(2*3) which equals 0.83 (because count is referenced by 3 methods and suit is referenced by 2 methods). If you do some calculations, you will find that well-written, “cohesive” classes have H-values near 1, and non-cohesive classes (those that can be readily rewritten into two classes without recoding many methods) have H-values less than 0.5. The net result is that using a cohesive component in a system means the system will have weak(er) coupling — the component does not cause a “cluster” of dependent components to form around it.