Model-View-ModelController – My take on MVVM – Introduction

January 9, 2009

I’ve seen a lot of examples from guys like Josh Smith and Karl Shifflett on best practices for using MVVM (Model-View-ViewModel). These are really great examples, but I have yet to find anyone doing real-world development in WPF on a LOB (line of business) application applying these principles.

I’m currently in development on a very large application and I will be writing a series of articles on the structure in which it is built including what I am calling Model-View-ModelController; a cross between MVVM and MVC. They obviously won’t entail any of the business specifics, but I want to demonstrate some of the patterns I am using to both give ideas to anyone struggling with the same issues I have and to also learn more through feedback from the community. Any and all feedback will be much appreciated.

The technologies I will be focusing on are WPF, and Linq-To-Sql. A few of the tenets I will be focusing on are

  • Views Instantiate the ModelControllers, and other Views
  • ModelControllers know NOTHING about the Views
  • ModelControllers instantiate Models and other ModelControllers
  • Models are simply DTO objects and have no knowledge of the existence of anything other than related Models

kick it on


Solution: Styling a large amount of controls

December 11, 2008

I’m really on this “Attached Property” kick. I’m probably totally over using them, but I think it’s such a powerful tool when used in the right scenario. I’m not really sure what the right scenario actually is, but I keep running into situations where to me they just make sense. Also there’s something about adding behavior to objects without actually inheriting from them that gives me a sense that I’m doing something really cool, cutting edge, and adventerous…alright that’s a little ridiculous. Moving on…

So I had posted a question on StackOverflow (by the way this is such an awesome site) and also wrote here about finding the best approach to applying styles to a large amount of controls. I spent an hour or so on the phone with Karl Shifflett discussing the pro’s and con’s of the various approaches to take which I wont re-hash here. I finally landed on this idea that uses my good buddy DependencyProperty.RegisterAttached.

What I’ve done is create 4 styles in a resource dictionary

  1. A style for the containing panel (i.e. Grid, StackPanel, etc.)
  2. A style for the first item(s)
  3. A style for the last items(s)
  4. A style for all the items in between


The reason I create different styles is that depending on where the object is in the panel I may want to apply more or less margin, or to different amounts on different sides. Obviously this is just one particular scenario, but you get the point. Then I set the the attached property on the containing grid like this (can also be a StackPanel/DockPanel):

<Grid local:AttachedProperties.IsStandardContainer="True">

Essentially what the attached property does is iterates through all the children in the Panel and applies one of the specified styles to each element. Care is taken not to override any explicit styles set on any child objects.

Here is a full example including the code for the attached property. Make sure you change the extension from .doc to .zip.

kick it on

CommandBindings in MVVM

December 10, 2008

Anyone who has tried to implement RoutedCommands in WPF using M-V-VM has undoubtedly run into issues. Commands (non-UI commands that is) should be implemented in the ViewModel. For instance if I needed to save a CustomerViewModel then I would implement that as a command directly on my CustomerViewModel. However if I wanted to pop up a window to show the users addresses I would implement a ShowCustomerAddress command directly in the view since this a UI specific function.

The problem lies in the way that RoutedCommands find their associated CommandBindings. In order for a command to be executed it has to have a CommandBinding which tells it how to handle the Executed and CanExecute events. When you associate a control with a command it walks up the logical tree to find the first command binding associated with it. A typical scenario would look like this:

<CommandBinding Command="ApplicationCommands.Save" CanExecute="Save_CanExecute" Executed="Save_Executed" />

<Button Command=”ApplicationCommands.Save” Content=”Save” />

This approach forces us to define the behavior of of the command directly in our view, when really that logic should be in the ViewModel. So how do we get the the View to look for the CommandBindings in the ViewModel instead of the baked in behavior of searching up the logical tree? Well, we can’t. So instead, we need a way to get the CommandBindings out of the ViewModel and into the View. The first thing we need is a CommandBindingCollection property in our ViewModel:

private readonly CommandBindingCollection _CommandBindings;
public CommandBindingCollection CommandBindings
      return _CommandBindings;

Now we create our CommandBindings and add them to the CommandBinding property we created:

public CustomerViewModel(Customer model)
//Create a command binding for the Save command
CommandBinding saveBinding = new CommandBinding(ApplicationCommands.Save, SaveExecuted, SaveCanExecute);

//Register the binding to the class
CommandManager.RegisterClassCommandBinding(typeof(CustomerViewModel), saveBinding);

//Adds the binding to the CommandBindingCollection

Now with a little Attached Property goodness we add the commandbindings of our ViewModel to our View:

public static DependencyProperty RegisterCommandBindingsProperty =  DependencyProperty.RegisterAttached("RegisterCommandBindings", typeof(CommandBindingCollection), typeof(AttachedProperties), new PropertyMetadata(null, OnRegisterCommandBindingChanged));

public static void SetRegisterCommandBindings(UIElement element, CommandBindingCollection value)
if(element != null)
element.SetValue(RegisterCommandBindingsProperty, value);
public static CommandBindingCollection GetRegisterCommandBindings(UIElement element)
return (element != null ? (CommandBindingCollection)element.GetValue(RegisterCommandBindingsProperty) : null);
private static void OnRegisterCommandBindingChanged
(DependencyObject sender, DependencyPropertyChangedEventArgs e)
UIElement element = sender as UIElement;
if (element != null)
CommandBindingCollection bindings = e.NewValue as CommandBindingCollection;
if (bindings != null)

This is how you would use it in the view:

<UserControl local:AttachedProperties.
RegisterCommandBindings="Binding CommandBindings}" >



There are few other examples of how to do this like Josh Smith posted on CodePlex, but I think this is a much more straightforward approach and requires less code. I really hope this helps someone dealing with the same issue. If you think there is a better way, please let me know.


There is a full example that you can download here. Be sure to change the file extension from .doc to .zip.
kick it on

Finding the Best Approach to Styling a LOB App

December 4, 2008

In my LOB apps I usually wind up with containers that contain a bunch of different TextBlocks and TextBoxes for users to enter data. Normally I need to apply a certain margin or vertical/horizontal alignment to each control.

Let’s say I have Grid on my form that looks like this (a lot of markup was eliminated for brevity):

   <TextBlock Text="MyLabel" />
   <TextBox Text={Binding ...}/>
   <!-- Repated a bunch more times along with all of the Grid.Row, 
Grid.Column definitions -->

Now let’s say I need every single item contained in my grid to have Margin=”3,1″ VerticalContentAlignment=”Left” VerticalAlignment=”Center”. There are several ways to achieve this:

  1. Set the properties directly on each control – BAD!! Does not allow for skinning or centralizing styles.
  2. Create a Style with an x:Key=”MyStyleName” and apply the style to each control. Better…Makes centralizing styles and skinning more manageable but still requires a ton of markup, and can become unwieldy.
  3. Create a global style (i.e. don’t specify an x:Key and set the TargetType={x:Type TextBox/TextBlock} – BAD!! The problem with this is that it affects ALL controls in the app that don’t explicity override this style. This can be bad for things like menus, grids, and other controls that use textblocks and textboxes.
  4. Create a style that targets the Grid and explicitely sets the dependecy propety values like <Setter Property="Frameworkelement.Margin" Value="3,1" /> Not bad…it correctly applies the style to every element in it’s content, but also applies it directly to the Grid itself…not exactly what I want.

So what approach do you take and why? What works the best?

kick it on

HeaderFormatString and ContentFormatString

November 17, 2008

I started exploring both HeaderFormatString and ContentFormatString and ran into a little weirdness.

First thing to note is this:

If you set the HeaderTemplate or HeaderTemplateSelector property of a HeaderedContentControl, the HeaderStringFormat property is ignored. MSDN

There are quite a few gotchas like this in WPF to watch out for.

Second thing to note is that these properties aren’t the same as doing this:
HeaderedContentControl and HeaderStringFormat are used specifically for classes that implement IFormattable. HederStringFormat formats the header, and ContentStringFormat formats the content. The value of either property is the format that gets passed to your classes implementation if IFormattable.ToString. You can read the full example on MSDN. But here is the gist of how to make it work.


This TabItem will now display “This is my formatted string” in the header, and the content will be “this is my non-formatted string”.


There a couple things to keep in mind. Typically these properties would be used in the context of an ItemsControl. The HeaderStringFormat would not be bound in this way, and instead will have the default binding provided by the ItemContainer of the HeaderedItemsControl. For instance if you set the ItemsSource property of the TabItem, then it will automatically wire up the header and the content binding for you, and all you have to do is supply the formatting value you want.

Last, but not least, I was able to get everything working properly with a GroupBox and TabItem, but not so much luck with an expander and I’m not sure why. The expander handles the ContentStringFormat properly, but not the HeaderContentStringFormat. This is suprising considering that the both inherit from HeaderContentControl…

kick it on

Consolidating XAML Namespaces

October 9, 2008

I’m working on a project that has numerous namespaces. Each time I need to use a class in XAML I have to add a new namespace declaration to the XAML file. This quickly becomes unwieldy when you start using multiple namespaces like this:


Then of course you have to figure out what namespace each item is in order to use in XAML.

An easy way around this is to consolidate all of the namespaces at the assembly level using the XmlnsDefinitionAttribute from the System.Windows.Markup namespace. In the AssemblyInfo.cs (or .vb) you add this attribute for each namespace you want to consolidate like this:



There is an optional parameter you can pass in that specifies which assemblies the namespaces live in. This allows you to consolidate namespaces across multiple assemblies.

Now back to our XAML, we can blow out all of these namespace declarations for a much simpler, cleaner approach:


kick it on

WPF Record Navigator (VCR) Control

October 5, 2008

I haven’t seen any examples of a record navigator in WPF so I decided to create one.

What it is:

  • Allows you to bind to a collection of elements and navigate through each one.

What it isn’t:

  • Currently it doesn’t have any hooks for styling.
  • The Current Index is read-only and can only be navigated using the buttons.

The implementation is pretty straight forward. It uses routed commands to handle all the navigation. The trick to making the implementation simple was to forward everything on to a ListBox. The template contains a ListBox named “PART_List” which has it’s visibility set to Collapsed. This allows me to bind the TextBlocks that display the Count and Current Position directly to the ListBox. Also for all of the navigation commands, the Command Executed handlers simply forward their calls to the corresponding methods on the ListBox. The ListBox also just binds it’s ItemsSource and IsSynchronizedWithCurrentItem directly to the corresponding Dependency Properties on the RecordNavigator.

I hope this control is useful to some of you. I’ll be further refining it to support styling and allow the user to jump to a specific index. Please give me any feedback you have. If there is any bugs or anything it should do that it doesn’t, please let me know.


You can download the code here: record-navigator. Make sure to change the extension from .doc to .zip.

kick it on