Introduction

Many pieces of the puzzle could already be found elsewhere. The application had to have a clear separation between data and view, i.e. an MVVM approach. Services had to be linked automatically with something like MEF. Data validation should be automatic (thanks to ValidationAttribute(s)).

But improvement had to be made regarding disconnected messaging and view resolution. About the view resolution, i.e. the process of finding the appropriate view to represent a given business data object, I wanted to just tag the view with an attribute, such as DataView(typeof(BusinessData1)) and let the library take care of the rest. This is where this library came from.

What's new?

Table of content

Samples

To test if my library was up to its goal I have ported three samples to it. In all case I was able to reduce the application size and maintain functionality.

• Josh Smith MVVM Demo. This is the best sample, as it is small and simple yet it covers almost all features of the library (after some modifications) and is a real composite application. I was able to get rid of the hand written validation code and use ValidationAttribute instead. And I tweaked the MainWindow and App class to make it a composite application, and use the DataControl in the TabItem to bind multiple controls to the same model with different view.
• Prism’s main sample, the StockTraderApp project (huge sample). I removed the presenters (code which were used to bind views and view models, now replaced with call to Composition.GetView() and DataControl), the EventAggregator and custom prism events (replaced by Notifications static method). The most challenging and interesting part was to get rid of the RegionManager and replace it with the IShellView which explicitly expose the area of the shell that can be used and get rid of the RegionManager’s magic string approach.
• MEFedMVVM library demo. The application is relatively simple but it makes extensive usage of design time support, and the design time experience is a joy to behold.

About MEF and MVVM

In MVVM the view is nothing more than some declarative XAML (and possibly some UI specific code if need be, with no business code at all just pure UI logic). And because business data might not express all the information present in a view (such as selected area, incorrect value in a text box, etc...), business models might be wrapped in view models. View models are business models wrappers with a few extra, view-friendly, properties. This offers various advantages including increased testability, better separation of concerns, possibility to have independent team for business data and UI.

MEF, or Manage Extensibility Framework, solves the problem of passing services and other shared objects around in a very neat way. It also enables to find interfaces implementations easily.
Basically “consumer” objects declare what they need with the import attribute, like so:

[Import(typeof(ISomeInterface)]
public ISomeInterface MySome { get; set; }

[Export(typeof(ISomeInterface))]
public class SomeInterfaceImplentation : ISomeInterface
{ /** */ }

1. At the start of the program, a “catalog” of types for MEF should be initialized from a list of types, assemblies and / or directories, which will be where MEF will look for locating exports. It’s where you opt-in for the modules of interest. With this library you’ll call the method Composition.Register(), as shown below.
2. You “compose” the objects that need to be resolved (i.e. which contains imports). With this library you’ll use the method Composition.Compose().

What does a composite application look like

The shell contains multiple areas where pluggable content will be hosted. Content that is not defined by the shell but in modules that are loaded dynamically (with MEF for example).

For example in the example below a shell is defined with two areas:

• A list box, showing a single list of documents.
• An ItemsControl (a TabControl) which can contains numerous items.

<Window 
	x:Class="DemoApp.MainWindow"
	xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
	xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml">
	<Grid>
		<Grid.ColumnDefinitions>
			<ColumnDefinition Width="Auto" />
			<ColumnDefinition Width="*" />
		</Grid.ColumnDefinitions>
		<ListBox
			Grid.Column="0"
			Items="{Binding Documents}"
			Header="Documents"
			/>
		<TabControl 
			Grid.Column="1"
			IsSynchronizedWithCurrentItem="True" 
			ItemsSource="{Binding Workspaces}" 
			ItemContainerStyle="{StaticResource ClosableTabItemStyle}"/>
	</ Grid >
</Window>

Once a shell has been defined, an interface to it should be exposed via a common library. It could be a “IShellInterface” (see the IShellView in the StockTraderApp for example) or its view model (see MainViewModel in DemoApp for example), or a combination of the two!

As an example here is the IShellView interface from the StockTraderApp sample:

public enum ShellRegion
{
	MainToolBar,
	Secondary,
	Action,
	Research,
	// this will set the currently selected item
	Main,
}
public interface IShellView
{
	void ShowShell(); // this will show the shell window
	void Show(ShellRegion region, object data);
	ObservableCollection<object> MainItems { get; }
}

1. Define the DLL that are to be dynamically loaded
2. Create the shell (or skip and import it in 3.)
3. Export the shell and import the modules
4. Start the app / initialize the modules

public partial class App
{
	public App()
	{
		// 1. Opt-in for the DLL of interest (for import-export resolution)
		Composition.Register(
			typeof(Shell).Assembly
			, typeof(IShellView).Assembly
			, typeof(MarketModule).Assembly
			, typeof(PositionModule).Assembly
			, typeof(WatchModule).Assembly
			, typeof(NewsModule).Assembly
			);
		// 2. Create the shell
		Logger = new TraceLogger();
		Shell = new Shell();
	}
 
	[Export(typeof(IShellView))]
	public IShellView Shell { get; internal set; }
 
	[Export(typeof(ILoggerFacade))]
	public ILoggerFacade Logger { get; private set; }
 
	[ImportMany(typeof(IShellModule))]
	public IShellModule[] Modules { get; internal set; }
 
	public void Run()
	{
		// 3. export the shell, import the modules
		Composition.Compose(this);
		Shell.ShowShell();
 
		// 4. Start the modules, they would import the shell
		// and use it to appear on the UI
		foreach (var m in Modules)
			m.Init();
	}
}

Core Features

The central class for most features of this library is the Composition class. It also contains two important properties, Catalog and Container, which are the used for MEF to resolve imports and exports. You need to fill the Catalog at the start of the application with Composition.Register(), for example:

static App() // init catalog in App’s static constructor
{
	Composition.Register(
		typeof(MapPage).Assembly
		, typeof(TitleData).Assembly
		, typeof(SessionInfo).Assembly
	);
}

Composition GetView

In this library the views need to be tagged with a DataViewAttribute which specifies for which model type this view is for:

[DataView(typeof(CustomerViewModel))]
public partial class CustomerView : UserControl
{
	public CustomerView()
	{
		InitializeComponent();
	}
}

public void ShowPopup(object message, object title)
{
	var sDialog = new MsgBox();
	sDialog.Message = Composition.GetView(message);
	sDialog.Title = Composition.GetView(title);
	sDialog.Show();
}

Remark It also brings a DataTemplate like functionality to Silverlight.

Because we use a View-Model approach, the same data model can be shown in multiple places at the same time hence Composition.GetView(), DataViewAttribute and the DataControl have an optional location parameter.

In the example below, the same UserViewModel instance (subclass of WorkspaceViewModel) is used to display both the TabItem header and content using different location parameter (note: location is not set, i.e.it is null, in the second template).

<Style x:Key="ClosableTabItemStyle" TargetType="TabItem" BasedOn="{StaticResource {x:Type TabItem}}">
	<Setter Property="HeaderTemplate">
		<Setter.Value>
			<DataTemplate>
				<g:DataControl Data="{Binding}" Location="header"/>
			</DataTemplate>
		</Setter.Value>
	</Setter>
	<Setter Property="ContentTemplate">
		<Setter.Value>
			<DataTemplate>
				<g:DataControl Data="{Binding}"/>
			</DataTemplate>
		</Setter.Value>
	</Setter>
</Style>

[DataView(typeof(CustomerViewModel))]
public partial class CustomerView : System.Windows.Controls.UserControl
{
	public CustomerView()
	{
		InitializeComponent();
	}
}
[DataView(typeof(WorkspaceViewModel), "header")]
public partial class CustomerHeaderView : UserControl
{
	public CustomerHeaderView()
	{
		InitializeComponent();
	}
}

Validation and ViewModelBase

The INotifyPropertyChanged implementation is strongly typed (refactor friendly):

public class Person : ViewModelBase
{
	public string Name
	{
		get { return mName; }
		set
		{
			if (value == mName)
				return;
			mName = value;
			OnPropertyChanged(() => Name); // See, no magic string!
		}
	}
	string mName;
}

public class Person : ViewModelBase
{
	[Required]
	public string Name { get; set; }
 
	[Required]
	public string LastName { get; set; }
 
	[OpenRangeValidation(0, null)]
	public int Age { get; set; }
 
	[PropertyValidation("Name")]
	[PropertyValidation("LastName")]
	[DelegateValidation("InitialsError")]
	public string Initials { get; set; }
 
	public string InitialsError()
	{
		if (Initials == null || Initials.Length != 2)
			return "Initials is not a 2 letter string";
		return null;
	}
}

ConversionValidationAttribute
DelegateValidationAttribute
OpenRangeValidationAttribute
PropertyValidationAttribute

A control with an invalid binding will automatically be surrounded by a red border (default style), but the error feedback can be customized as shown in this XAML fragment below, which display the error message below the validated text:

<!-- FIRST NAME-->
<Label 
	Grid.Row="2" Grid.Column="0" 
	Content="First _name:" 
	HorizontalAlignment="Right"
	Target="{Binding ElementName=firstNameTxt}"
	/>
<TextBox 
	x:Name="firstNameTxt"
	Grid.Row="2" Grid.Column="2" 
	Text="{Binding Path=Customer.FirstName, ValidatesOnDataErrors=True, UpdateSourceTrigger=PropertyChanged, BindingGroupName=CustomerGroup}" 
	Validation.ErrorTemplate="{x:Null}"
	/>
<!-- Display the error string to the user -->
<ContentPresenter 
	Grid.Row="3" Grid.Column="2"
	Content="{Binding ElementName=firstNameTxt, Path=(Validation.Errors).CurrentItem}"
	/>

Disconnected Messaging

First a common message type should be defined in a common library, objects can

• Subscribe to messages for this type (with the static Subscribe() and Register() methods).
• Publish messages (with Publish()).
• Unsubscribe from messages if they are no longer interested in them (with Unsubscribe()).

To illustrate these functionalities here is a snippet of code from the Notifications’ unit test class.

public void TestSubscribe()
{
	// subscribe to a message
	Notifications.Subscribe<NotificationsTests, MessageData>(null, StaticSubscribed, ThreadOption.PublisherThread);

	// publish a message
	Notifications.Publish(new MessageData { });

	// unsubscribe to a message below
	Notifications.Unsubscribe<NotificationsTests, MessageData>(null, StaticSubscribed);
}
 
static void StaticSubscribed(NotificationsTests t, MessageData md)
{
	// message handling
}

public void TestRegister()
{
	// register to multiple message type (1 shown below)
	Notifications.Register(this, ThreadOption.PublisherThread);

	// publish a message
	Notifications.Publish(new MessageData { Info = "h" });
}
 
[NotificationHandler]
public void Listen1(MessageData md)
{
	// message handling
}

Commands

ViewModels need to expose a Command property whose Execute() method will call one of their methods. For this purpose there is the DelegateCommand.

A delegate command can be created by passing a method to execute and an optional method to check if the method can be executed (which will enable / disable the command source, i.e. the button). For example:

var p = new Person();
var save = new DelegateCommand(p, () => p.CanSave);

Remark Sometimes you need commands such as “DoAll” as in “CancelAll” or “BuyAll” hence the support of ForeachCommand class, which is an ICommand itself and can watch a list of ICommand, set its status to CanBeExecuted if all its command can be executed.

Utilities

UIThread Invoke

public class Invoker
{
	public static void BeginInvoke(Delegate method, params object[] args)
	public static void DelayInvoke(TimeSpan delay, Delegate method, params object[] args)
}

Design time model initialization

<UserControl x:Class="MEFedMVVMDemo.Views.SelectedUser"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml
		xmlns:g="http://schemas.galador.net/xaml/libraries"
		xmlns:models="clr-namespace:MEFedMVVMDemo.ViewModels"
		g:Composition.DesignerDataContext="models:SelectedUserViewModel"
		>

Remark Having a design time DataContext makes the experience of writing a DataTemplate a whole lot better.

Remark These view models can be made aware that they are in design mode if they implement the IDesignAware interface.

Remark The services loaded by the models can be different in runtime and design time if they are exported with ExportService instead of Export, like so

[ExportService(ServiceContext.DesignTime, typeof(IUsersService))]
public class DesignTimeUsersService : IUsersService

POCO Bindings

var p1 = new Person();
var p2 = new Person();
POCOBinding.Create<Person, Person, int>(p1, aP => aP.Boss.Age, p2, aP2 => aP2.Age);

var p1 = new Person();
var pp = PropertyPath.Create<string>(() => p1.Boss.Name);

//.....
pp.Value = "Foo";
Assert.AreEqual(p1.Boss.Name, "Foo");

Foreach

Summary

• Resolving services dependencies using MEF.
• Finding DataView for DataModel with DataControl or Composition.GetView().
• Implement common MVVM pattern: the ICommand (with DelegateCommand and ForeachCommand) and disconnected messaging (with Notifications).
• Implement data binding validation with ValidationAttribute in a subclass of ViewModelBase.

Compatibility

If need to be ported to .NET3.5 there are two obstacles.

• MEF, which is on CodePlex.
• And the Validator class, used in the ViewModelBase to validate the properties from the ValidationAttribute(s), i.e. implement the IDataErrorInfo interface. Only two methods need to be reimplemented from the Validator.

References

Prism, aka the composite application library
http://compositewpf.codeplex.com/

Josh Smith on MVVM
http://msdn.microsoft.com/en-us/magazine/dd419663.aspx

Rob Eisenberg on MVVM
http://devlicio.us/blogs/rob_eisenberg/archive/2010/03/16/build-your-own-mvvm-framework-is-online.aspx

The MEFedMVVM library
http://mefedmvvm.codeplex.com