Introduction
The Model-View-Controller (MVC) design pattern is a powerful way to separate the concerns of the user interface, the data model, and the state management of both. Events are used to achieve this decoupling. Both the model and view are well suited for declarative programming. The model manages the data, being a collection of fields with a known type, and the view is a representation of the user interface as expressed by a collection of controls. The controller is best constructed in code, as it contains the logic for responding to the events fired by the view and adjusting the model's state.
In a classic MVC pattern, the view does not directly change the model's state (as in, field values managed by the model). Instead, it fires events to the controller. The controller contains the logic to decide how the model state changes and informs the model of the appropriate state change with a direct function call. The model, upon processing the state change, fires an event which is received by the view(s). The view adjusts the state of the UI to reflect the state change of the model.
When data binding is employed, the model and view have a direct communication path that is managed by the underlying framework rather than the application. If the view changes, the field's value in the model is automatically updated. Conversely, if the field's value in the model changes, the view is automatically updated. The controller never intervenes unless the Binding class' Parse event is handled. However, this event is intended to provide custom unformatting of displayed values rather than state management, so it's not the appropriate use of the event.
A Working Example
I am going to illustrate the MVC pattern using MyXaml as the declarative syntax. A simple example is a date-range picker, which is a common enough dialog used to select the date ranges of reports:
Declaratively Creating The Model
The model for this UI manages the following fields:
- start date
- end date
- selected default date range option
- group by index
This is expressed declaratively by constructing a container in the markup:
<MxContainer Name="DateSelection">
<MxProperties>
<MxProperty Name="StartDate" Type="DateTime"/>
<MxProperty Name="EndDate" Type="DateTime"/>
<MxProperty Name="Option" Type="int"/>
<MxProperty Name="GroupBy" Type="int"/>
</MxProperties>
</MxContainer>
Now, we have a problem. Data binding works with fields only through corresponding property "get" and "set" methods. We can't abstract this concept with data binding, so instead, we have to generate at runtime the code for the class that represents this container and instantiate it. The MxContainer class, when instantiated by the MyXaml parser and all the parsing of the class is complete, does exactly this. The following code is auto-generated:
using System;
using System.Collections;
using MyXaml.Extensions;
namespace MyXaml.App.Container
{
public class DateSelection : MxDataContainer
{
protected DateTime startDate;
protected DateTime endDate;
protected int option;
protected int groupBy;
public DateTime StartDate
{
get {return startDate;}
set {startDate=value;}
}
public DateTime EndDate
{
get {return endDate;}
set {endDate=value;}
}
public int Option
{
get {return option;}
set {option=value;}
}
public int GroupBy
{
get {return groupBy;}
set {groupBy=value;}
}
}
}
Initial values must also be established if they are not defined in the MxProperty element, otherwise the data binding fails for objects such as DataTime. This also is handled by the MxContainer class. The resulting instance of the DateSelection class is put into the parser's object pool. Later on, I will discuss why the class is derived from MxDataContainer.
Declaratively Creating The UI
The user interface is generated with the typical declarative syntax:
<Style def:Name="RangeStyle">
<StyleProperties>
<PropertyStyle Class="MxRadioButton" Size="80, 20"/>
</StyleProperties>
</Style>
<Controls>
<Label Location="10, 10" Size="220, 15" Text="Select A Date Range"
TextAlign="MiddleCenter"/>
<Label Location="10, 42" Size="70, 15" Text="Start Date:"/>
<Label Location="10, 67" Size="70, 15" Text="End Date:"/>
<DateTimePicker Location="80, 40" Size="100, 20" Format="Short">
<DataBindings>
<MxDataBinding PropertyName="Value" DataSource="DateSelection"
DataMember="StartDate"/>
</DataBindings>
</DateTimePicker>
<DateTimePicker Location="80, 65" Size="100, 20" Format="Short">
<DataBindings>
<MxDataBinding PropertyName="Value" DataSource="DateSelection"
DataMember="EndDate"/>
</DataBindings>
</DateTimePicker>
<GroupBox Location="10, 95" Size="220, 110" Text="Default Options:">
<Controls>
<MxRadioButton Location="10, 20" Size="80, 15" Text="Today">
<DataBindings>
<MxDataBinding PropertyName="Index" DataSource="DateSelection"
DataMember="Option"/>
</DataBindings>
</MxRadioButton>
<MxRadioButton Location="10,40" Text="This week" MxStyle="{RangeStyle}"/>
<MxRadioButton Location="10,60" Text="This month" MxStyle="{RangeStyle}"/>
<MxRadioButton Location="10,80" Text="This year" MxStyle="{RangeStyle}"/>
<MxRadioButton Location="120,20" Text="Yesterday" MxStyle="{RangeStyle}"/>
<MxRadioButton Location="120,40" Text="Last week" MxStyle="{RangeStyle}"/>
<MxRadioButton Location="120,60" Text="Last month" MxStyle="{RangeStyle}"/>
<MxRadioButton Location="120,80" Text="Last year" MxStyle="{RangeStyle}"/>
</Controls>
</GroupBox>
<GroupBox Location="235, 95" Size="100, 110" Text="Group By:">
<Controls>
<MxRadioButton Location="10, 20" Size="70, 20" Text="Hour">
<DataBindings>
<MxDataBinding PropertyName="Index" DataSource="DateSelection"
DataMember="GroupBy"/>
</DataBindings>
</MxRadioButton>
<MxRadioButton Location="10, 40" Size="70, 20" Text="Day"/>
<MxRadioButton Location="10, 60" Size="70, 20" Text="Month"/>
<MxRadioButton Location="10, 80" Size="70, 20" Text="Year"/>
</Controls>
</GroupBox>
<Button def:Name="OKButton" Location="250, 10" Size="80, 25" Text="OK"
FlatStyle="System" Click="OnDlgOK"/>
<Button def:Name="CancelButton" Location="250, 35" Size="80, 25"
Text="Cancel" FlatStyle="System" Click="OnDlgCancel"/>
</Controls>
Data Binding Problems
Unfortunately, data binding comes with its own set of problems, some of which I am illustrating here.
The first and by far most annoying problem is when using data binding with regards to a radio button. Radio buttons are unique because, as the programmer, we're almost always interested in which button in the group was selected. Data binding only offers us the ability to bind to each property of each individual button. This means that we would need separate properties in the container, and this defeats the index-like quality of the radio button. To solve this problem, the MxRadioButton is a class that extends the RadioButton functionality by implementing an Index property. By binding to this property, the MxRadioButton class intelligently sets the Checked state of the appropriate radio button in the group.
Second, when the Click event fires on the RadioButton, the data binding update has not yet occurred! This means that we have to inspect the value of the control directly, rather than the property value being managed by the container. Again, to deal with this problem, the base class of the container, MxDataContainer, forces a transfer of the data to and from the control when we respectively set and get the value of the property in the container.
The good thing is, once these fixes are in place, they can be used over and over again in all of our applications.
Container Problems
The container is generated at runtime, so your compile-time code doesn't know anything about it. This means that you have to use a separate vehicle for accessing the properties in the container. Hence the reason for the container's base class, MxDataContainer. This is a class known at your application's compile time, and can be used to access the properties of the runtime compiled container. While awkward, it also has an advantage--the container's data representation is decoupled from the controller, allowing the two to vary independently, which has some advantages.
The Controller
In our controller for this UI, we want to do two things:
- When a default date range is selected, automatically adjust the beginning and ending dates.
- When the user changes the beginning or ending date, "uncheck" all radio buttons in the default range group.
Handling User Gesture Events
There are a variety of ways that this can be done, but in keeping with the MVC pattern, we want the view decoupled from the controller. In other words, the view doesn't call a method in the controller. Ideally, the view should consume any Control events and provide the controller with a "sanitized" version of the event. If the controller were to directly consume the Control's event, then a level of decoupling would be lost. This would become apparent if the view were to change and the new Control's event had a different EventArgs signature. This would break the controller's implementation.
The Event Pool that I've written about in a previous article is a nice way of managing this requirement. It also has several advantages:
- it documents the producers and consumers of events;
- it instruments the events;
- it provides a safe mechanism for invoking the events, regardless if there is a consumer or not.
The question then remains, does the view pass along any data to the controller? We could easily put selection information into the Tag property of the radio buttons. But we already have a property in the container that can be used to get the current selection, so it seems more logical (and simpler) to use the container. The drawback to this is that it assumes that the property in the container will always have a data binding to the control, however it is implemented. This decision will have to be left to the programmer, based on what his/her crystal ball says regarding the possible views that might be encountered in the future. But, since the Control class, from which all controls are derived, contains the DataBindings collection, it's reasonable to say "always use data binding with a property in the container". That said, we probably don't ever have to worry about whether the view needs to pass parameters to the controller--all the relevant information should be in the container model.
Mapping Control Events
As a result of the decisions made regarding handling Control events, it would be nice if we could just map the Control event to an appropriate user gesture event managed by the EventPool. Yes, this seems like an unnecessary step in such a trivial example, but the beauty of it lies in the fact that, once handled by the EventPool, the event is instrumented! This means that we now have an automatic trace of user actions regarding what the guy in QA did, when upon being asked "how did you break it?", he replies "I dunno". This single feature has reduced QA acceptance time by two-thirds in projects on which I have worked. So, even for something that seems like unnecessary complication, there are great benefits.
Because each radio button represents a different state that we want to set in the model, it makes sense to create a separate event handler for each Click event from the RadioButton control. Therefore, we don't need to inspect the Option property of the container and we avoid a switch statement.
Since the event pool implements multicast delegates, each event managed by the pool can have more than one subscriber. Again, we can use XML to declaratively establish the connection between the Control event in the View, the corresponding EventPool event, and the handler that subscribes to the event. The ControlEvents collection handles the mapping of the control event to the corresponding EventPool event. The Subscribers collection manages the mapping of the EventPool event to one or more subscribers.
<ev:EventPool def:Name="DateRangeEventPool">
<ev:ControlEvents>
<ev:ControlEvent Control="{rbToday}"
Event="Click" MapTo="SelectToday"/>
<ev:ControlEvent Control="{rbWeek}"
Event="Click" MapTo="SelectThisWeek"/>
<ev:ControlEvent Control="{rbMonth}"
Event="Click" MapTo="SelectThisMonth"/>
<ev:ControlEvent Control="{rbYear}"
Event="Click" MapTo="SelectThisYear"/>
<ev:ControlEvent Control="{rbYesterday}"
Event="Click" MapTo="SelectYesterday"/>
<ev:ControlEvent Control="{rbLastWeek}"
Event="Click" MapTo="SelectLastWeek"/>
<ev:ControlEvent Control="{rbLastMonth}"
Event="Click" MapTo="SelectLastMonth"/>
<ev:ControlEvent Control="{rbLastYear}"
Event="Click" MapTo="SelectLastYear"/>
<ev:ControlEvent Control="{StartDate}"
Event="ValueChanged" MapTo="CustomDate"/>
<ev:ControlEvent Control="{EndDate}"
Event="ValueChanged" MapTo="CustomDate"/>
</ev:ControlEvents>
<ev:Subscribers>
<ev:Subscriber Event="SelectToday" Instance="{DateRangeController}"
Handler="OnSelectToday"/>
<ev:Subscriber Event="SelectThisWeek" Instance="{DateRangeController}"
Handler="OnSelectThisWeek"/>
<ev:Subscriber Event="SelectThisMonth" Instance="{DateRangeController}"
Handler="OnSelectThisMonth"/>
<ev:Subscriber Event="SelectThisYear" Instance="{DateRangeController}"
Handler="OnSelectThisYear"/>
<ev:Subscriber Event="SelectYesterday" Instance="{DateRangeController}"
Handler="OnSelectYesterday"/>
<ev:Subscriber Event="SelectLastWeek" Instance="{DateRangeController}"
Handler="OnSelectLastWeek"/>
<ev:Subscriber Event="SelectLastMonth" Instance="{DateRangeController}"
Handler="OnSelectLastMonth"/>
<ev:Subscriber Event="SelectLastYear" Instance="{DateRangeController}"
Handler="OnSelectLastYear"/>
<ev:Subscriber Event="CustomDate" Instance="{DateRangeController}"
Handler="OnCustomDate"/>
</ev:Subscribers>
</ev:EventPool>
To make this all work, we again rely on runtime code generation to create the appropriate bridge class. The emitted code looks like this:
using System;
using System.Collections;
using MyXaml.EventManagement;
using MyXaml.Extensions;
namespace MyXaml.App.ControlEvents
{
public class DateRangeEventPool : IEventPool
{
protected EventPool eventPool;
public EventPool EventPool
{
get {return eventPool;}
set {eventPool=value;}
}
public void Click_SelectToday(object sender, EventArgs e)
{
eventPool.FireEvent("SelectToday");
}
public void Click_SelectThisWeek(object sender, EventArgs e)
{
eventPool.FireEvent("SelectThisWeek");
}
public void Click_SelectThisMonth(object sender, EventArgs e)
{
eventPool.FireEvent("SelectThisMonth");
}
public void Click_SelectThisYear(object sender, EventArgs e)
{
eventPool.FireEvent("SelectThisYear");
}
public void Click_SelectYesterday(object sender, EventArgs e)
{
eventPool.FireEvent("SelectYesterday");
}
public void Click_SelectLastWeek(object sender, EventArgs e)
{
eventPool.FireEvent("SelectLastWeek");
}
public void Click_SelectLastMonth(object sender, EventArgs e)
{
eventPool.FireEvent("SelectLastMonth");
}
public void Click_SelectLastYear(object sender, EventArgs e)
{
eventPool.FireEvent("SelectLastYear");
}
public void ValueChanged_CustomDate(object sender, EventArgs e)
{
eventPool.FireEvent("CustomDate");
}
}
}
At this point, you are probably thinking that Marc has really gone off his rocker this time! He's managed to create a bunch of time-consuming runtime generated code that replaces the very simple mechanism in .NET of wiring up an event to a handler!
And, in a sense, you are correct.
However, let's look at what all of this does:
- I have eliminated the need to, in code, wire up events. OK, MyXaml did that already.
- All View events are now instrumented. Cool! I can track what I do, and why the program breaks!
- In .NET, the wiring up of the event requires that the code has both knowledge of the
Control class and the instance (the Controller) that handles the event. I have eliminated that coupling. Ahhh! Now, MyXaml did that already, but the event signature was bound to the Control type. This is more abstract.
- It creates an architectural pattern that helps me write better code. The Controller now represents a set of methods that manages the Model state. Typical implementations embed the model state management as part of the subclassed Form, at least, if you follow Visual Studio's way of generating event handlers. The "Microsoft Way" makes it impossible to implement an MVC pattern, results in costly code rewrites when the View changes, and in general, bogs down the flexibility of the application.
The Controller implementation is straight forward, which we'll add as in-line code to the markup so we get a complete stand-alone package (yes, I wrote this code first as an assembly, debugged it, then copied it into the markup):
<def:Code language="C#">
<reference assembly="System.Drawing.dll"/>
<reference assembly="System.Windows.Forms.dll"/>
<reference assembly="myxaml.dll"/>
<![CDATA[
using System;
using System.ComponentModel;
using System.Drawing;
using System.Windows.Forms;
using MyXaml;
using MyXaml.Extensions;
public class DateRangeController
{
protected Parser parser;
protected MxDataContainer dateSelection;
protected TimeSpan oneDay;
public DateRangeController()
{
parser=Parser.CurrentInstance;
parser.AddReference("DateRangeController", this);
oneDay=new TimeSpan(1, 0, 0, 0);
}
public void DateSelectionLoaded(object sender, EventArgs e)
{
dateSelection=(MxDataContainer)parser.GetReference("DateSelection");
}
public void OnSelectToday(object sender, EventArgs e)
{
dateSelection.SetValue("StartDate", DateTime.Now);
dateSelection.SetValue("EndDate", DateTime.Now);
}
public void OnSelectThisWeek(object sender, EventArgs e)
{
DateTime dt=DateTime.Now;
dateSelection.SetValue("EndDate", dt);
while (dt.DayOfWeek != 0)
{
dt-=oneDay;
}
dateSelection.SetValue("StartDate", dt);
}
public void OnSelectThisMonth(object sender, EventArgs e)
{
DateTime dt=DateTime.Now;
dateSelection.SetValue("EndDate", dt);
dt=new DateTime(dt.Year, dt.Month, 1, dt.Hour, dt.Minute, dt.Second);
dateSelection.SetValue("StartDate", dt);
}
public void OnSelectThisYear(object sender, EventArgs e)
{
DateTime dt=DateTime.Now;
dateSelection.SetValue("EndDate", dt);
dt=new DateTime(dt.Year, 1, 1, dt.Hour, dt.Minute, dt.Second);
dateSelection.SetValue("StartDate", dt);
}
public void OnSelectYesterday(object sender, EventArgs e)
{
DateTime dt=DateTime.Now;
dt=dt - oneDay;
dateSelection.SetValue("StartDate", dt);
dateSelection.SetValue("EndDate", dt);
}
public void OnSelectLastWeek(object sender, EventArgs e)
{
DateTime dt=DateTime.Now;
while (dt.DayOfWeek != 0)
{
dt-=oneDay;
}
dateSelection.SetValue("EndDate", dt);
dt-=new TimeSpan(7, 0, 0, 0);
dateSelection.SetValue("StartDate", dt);
}
public void OnSelectLastMonth(object sender, EventArgs e)
{
DateTime dt=DateTime.Now;
dt=new DateTime(dt.Year, dt.Month, 1, dt.Hour, dt.Minute, dt.Second);
dt=dt.AddMonths(-1);
dateSelection.SetValue("StartDate", dt);
dt=new DateTime(dt.Year, dt.Month, DateTime.DaysInMonth(dt.Year, dt.Month),
dt.Hour, dt.Minute, dt.Second);
dateSelection.SetValue("EndDate", dt);
}
public void OnSelectLastYear(object sender, EventArgs e)
{
DateTime dt=DateTime.Now;
dt=new DateTime(dt.Year, 1, 1, dt.Hour, dt.Minute, dt.Second);
dt=dt.AddYears(-1);
dateSelection.SetValue("StartDate", dt);
dt=new DateTime(dt.Year, 12, 31, dt.Hour, dt.Minute, dt.Second);
dateSelection.SetValue("EndDate", dt);
}
public void OnCustomDate(object sender, EventArgs e)
{
string dtStart1=
((DateTime)dateSelection.GetContainerValue("StartDate")).ToShortDateString();
string dtStart2=
((DateTime)dateSelection.GetValue("StartDate")).ToShortDateString();
string dtEnd1=
((DateTime)dateSelection.GetContainerValue("EndDate")).ToShortDateString();
string dtEnd2=
((DateTime)dateSelection.GetValue("EndDate")).ToShortDateString();
if ( (dtStart1 != dtStart2) || (dtEnd1 != dtEnd2) )
{
dateSelection.SetValue("Option", -1);
}
}
}
]]>
</def:Code>
A Different View
Now, none of this would be of much value if I didn't demonstrate changing the view without affecting the model or the controller. So, in this UI:
I have replaced the radio buttons with a ComboBox. Now, this begs the question--where should we put the logic for figuring out which action to take when the user makes a selection? Does this go in the View or the Controller? There really isn't that good of an answer--in this particular case, I've decided to demonstrate both. However, I feel that since the combobox is an active selection that changes the UI state, the View should be responsible. The View manages the list and applies meaning to the list contents, and it also doesn't require changing the Controller code. I've demonstrated both approaches in the download.
The elegance of separating the View from the Model/Controller is seen in the next example. Swapping out:
<ComboBox def:Name="cbOption" Location="10, 20" Size="200, 20"
SelectionChangeCommitted="OnSelectChangeCommitted">
<Items>
<Item>Today</Item>
<Item>This Week</Item>
<Item>This Month</Item>
<Item>This Year</Item>
<Item>Yesterday</Item>
<Item>Last Week</Item>
<Item>Last Month</Item>
<Item>Last Year</Item>
</Items>
<DataBindings>
<MxDataBinding PropertyName="SelectedIndex" DataSource="DateSelection"
DataMember="Option"/>
</DataBindings>
</ComboBox>
with:
<ListBox def:Name="cbOption" Location="10, 20" Size="200, 80"
SelectedIndexChanged="OnSelectedIndexChanged">
etc...
and we have changed the View, independent of the Controller:
Conclusion
The MVC pattern is very powerful. By using declarative programming, a lot of the drudgery in creating classes and wiring up events can be eliminated. The examples I've illustrated here are somewhat trivial. In a complicated UI, however, where a single Form may have multiple Views that are being managed, or the selection in one View affects the state in another, this technique becomes very useful. Also note that in the examples I've provided, I've put the Model, View and Controller code in the same file as the markup. This creates a physical binding between the three, which in real life you would probably not do. Finally, this is very much a concept piece. I'm using this technique for my own application development, and I suspect that it will mature further as time goes on.
References
