Skip navigation

So I am acutely aware that there is some confusion in the world about just what MVC is. I thought the paradigm I have been using for WPF would be considered MVC but after further research, I learned that while it is technically MVC, it is not what will first come to mind when you hear MVC. What I have been doing is making the View totally dumb. The only "knowledge" it has of the Model is imparted to it through databindings against properties exposed to it through my Controller. With "Pure" MVC, the View has a knowledge of the Model and can even act on it directly in some cases.

Doing a little more digging, I thought that I had found a name to the design pattern I have been using: Passive View. Martin Fowler’s definition of the Passive View definitely fits the bill for what I do:

A screen and components with all application specific behavior extracted into a controller so that the widgets have their state controlled entirely by controller.

Martin’s description of the passive view says that it’s primary benefit is that it makes your application more testable. I definitely have seen that benefit. I also have noticed that my code is more flexible to change when using this design.

However, I must point out that my Controller doesn’t actively update the view. It exposes properties that the View binds against. I also couple my MVC with the Command pattern (WPF really lends itself to the Command pattern seeing that it has the ICommand interface and certain UI elements have Command properties on them). All of my Controllers have a command that they expose for binding by the View, you could implement INotifyPropertyChanged, but I have been using Dependency Properties to handle all of those nuances.

Here is an example of how I would code a UI to all a user to search for an order in a customer service application. First we have the command OrderSearch (it might be an extension to a base Search Command or it might be the rSearch command with a Parameter SearchRequest that has an SearchType property (either way there will be an SearchRequest parameter). In this instance, my controller would also expose properties such as AvailableSearchFields, SelectedSearchField, SelectedSearchValue, and Results.

The View (in this case a UserControl subclass) would have its DataContext set to an instance of the Controller. There would be a ComboBox with its ItemsSource="{Binding AvailableSearchFields}" and SelectedItem="{Binding SelectedSearchField}". There is also a TextBox with its Text="{Binding SelectedSearchValue}" and a Button Command="{Binding Command}".

The only code behind required is the constructor which creates the controller and sets the control’s datacontext to the controller. (And that’s actually handled in the base class of the UserControl).

As you can see, there is NO logic in the UserControl, it only binds to (or observes) the Controller. Also, the Controller has no logic that deals with the UserControl directly…it only exposes properties, and performs logic in response to values being set.

The more I think about this pattern, the less it seems that it exactly matches Passive View, because Passive View implies that the Controller actually performs actions on the View. Again, my controller has no knowledge whatsoever of the view. It is not "Pure" MVC either because the View has no knowledge of the Model…I think this does follow the pattern that Dan Crevier described with Model – View – ViewModel. After going back and reading his blog further, this is exactly what this pattern is. I must have subconciously followed it. Anyway, I guess that this is just confirmation that it is definitely a pattern that works.

Using this pattern, my code is orders of magnitude more flexible and testable than using the code behind to drive the UI. I would also argue that it lends itself toward an SOA approach because of the Commands that are used to drive actions. In theory the same controller could be used to expose functionality to a website or to a Winforms UI. In order to do that, we’d probably want to move away from using DependencyProperties and instead implement INotifyPropertyChanged. Also we’d want to move from the WPF specific Command and create a Converter from our custom Command to WPF’s ICommand.

While I was putting my thoughts together on this posting, Paul Stovell again one upped me and posted his thoughts on "Binding Oriented Programming". He is more or less following the same pattern I use for WPF development.

Technorati tags: , ,


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: