Model-View-Controller Pattern

Model-View-Controller (MVC) is a classic design pattern often used by large/complex applications that need the ability to maintain multiple views of the same data. The MVC pattern relies on a clean separation of objects into one of three classes.

• models for maintaining state [data]
• views for displaying data [display logic] - forms
• controllers for handling events that affect the model or view(s) [business logic]

What interests me here is the interaction between these three classes. I'm in the middle of refactoring the user-interface of a quite complex Windows Forms application with lots of usercontrols and the interaction between the classes has been an interesting point of discussion in our development-team.

But let me first explain why we decided to refactor. As I mentioned earlier, the application consists of many complex views and in the beginning all "actions" towards the GUI (top-down) occurred through events. While the application was growing, this event-handling-system became more and more the bottleneck of our application because some events were firing more than desired and a lot of events fired on their turn other events and so on ... Bottomline : we didn't have full control anymore over our event-handling-system (bad performance) and debugging this was a real disaster! That's the reason why we wanted to refactor and to move to a solid implementation of the MVC pattern.

After many brainstorm-sessions we've decided the following interactions between the 3 classes :

• user input occurs on the View(s)
• the View notifies the Controller of a change by raising an event to the Controller.
  Example (code for controller)
  //ButtonClick event is handled on controller
  //Property MyButton is defined on myView
  myView.MyButton.Click += new System.EventHandler(this.myButton_Click);
• the Controller modifies the Model directly using its properties
  Example (code for controller)
  //Property of model is set to true
  myModel.DoProcessing = true;
• the Controller initiates method calls (actions) on the Views to update the GUI
  Example (code for controller)
  //Call method "RefreshListView" on myView
  //Pass Property (Dataset) of Model
  myView.RefreshListView(myModel.MyDataSet);

The most important decision was to eliminate eventhandling for top-down interaction : Controller --> View. All these events are now being replaced by direct method calls. Eventhandling is now only possible bottom-up : View --> Controller. In that way we hope to gain back full control over our GUI. Debugging will also become more attractive. Our implementation of the MVC-pattern is maybe not appropriate for other projects, but we believe that it is the best way to solve our problems.

After implementation a lot of (manual) testing will be needed to be sure that everything that worked before is still working! MVC does not eliminate the need for user interface testing. Creating automated tests for user interfaces is generally more difficult and time-consuming than for business logic. Therefore, reducing the amount of code that is directly tied to the user interface will also enhance the testability of the application.