Implementing the MVC Pattern
The sample application illustrates a work situation where multiple programmers each independently develop their own pieces of the user interface. Those separate pieces are then integrated together at run time into a common visual framework. You can think of each piece as an add-in or snap-in. Each one adds custom functionality to an otherwise empty user interface shell. Consider a standard form. If two different programmers attempt to add functionality to the same form at the same time, you typically end up with either two versions of the form, which you would later need to merge into one coherent whole, or worse, one programmer inadvertently overwrites the other's work. However, if each programmer works separately on a discrete piece of the form—for example a panel, the menu, a toolbar, or a tab control, and those pieces function independently, you can easily integrate them in code, and they will work together as planned.

To make this collaboration work, you need to introduce another pattern into the mix: the Mediator pattern. A Mediator coordinates the interaction between other classes. The sample code uses Mediators to initialize one or more Views. The Mediator thus becomes the entry point for each programmer's add-ins. The Mediator's job is to coordinate interaction between the user interface framework and the View(s) that it controls. For example, the Mediator would add items to the main menu, and react to their click events by displaying the appropriate View.

The sample code (see the download link in the left column of this article) has three projects:

• The MVCLibrary project contains the abstract classes for the framework
• The MVCMediators project is an implementation of the abstract classes. These represent a sample add-in to the framework.
• The MVCSample project contains an empty user interface framework for the application and includes the application's primary window (in this case an MDI container form), which is responsible for loading the various MVCMediator implementations.

To get started, look at the code in MVCLibrary project, which contains the abstract classes (see Table 1) that programmers use to create their implementations.

Table 1 shows the classes in the MVCLibrary project, their relationship to a pattern, and a brief description of each.

Pattern	Class	Description
Observer Pattern	clsSubject	Base class for classes who will be sending out events
	IObserver	Interface implemented by classes who need to register for events from other classes
	clsEvent	Generic event class. It can be used as is, or specialized for special needs.
MVC Pattern	clsModel	Base class that your Model must inherit from.
	frmView	Base class for implementing a new View.
	clsController	Base class for implementing new Controllers.
Mediator	clsMediator	Base class for creating new mediators.