Introduction

When we create LOB (Line-of-business) applications, we use to develop them in a modular way, to satisfy many requisites:

• The application is sold by modules – the customer can buy the sales module, but not the industrial one.
• The application can be developed by separated teams – each team develops an independent module.
• The modules are only loaded when the user needs it.
• The application doesn’t need to be completely redeployed when a module changes
• We can create new modules and add them to the application with no need to change the other modules.

To create a modular application we must create a custom infrastructure that needs lots of work and can introduce bugs to the system

.Net 4.0 brought a new resource that allows us to create modular and extensible applications: MEF (Managed Extensibility Framework). This is a framework to create extensible apps and it is thoroughly tested – Visual Studio uses MEF for its extension system: when you use a Visual Studio add-in, you are using MEF.

Introduction to MEF

Before developing out modular application, we will see how to use MEF. To use it, you must include a reference to System.ComponentModel.Composition. After adding the reference we must tell to the program which are the parts that must be combined: on one side, we have the exported classes, the modules that will be added to the main module, that will fit in the imported parts.

To do this association and the module discovery, combining the exported parts to the imported ones we use Containers. They will discover the modules and will combine the exported to the imported parts. Containers can use catalogs to find the application parts. Does this seem difficult? Let’s see how does it work in the real world.

Create a new console project and add a reference to System.ComponentModel.Composition. Create a new class and call it Menu:

public class Menu
{
    private Module _module;
    public void OptionList()
    {
       Console.WriteLine(_module.Title);
    }
}

We need to create the Module class:

public class Module
{
    public Module()
    {
        Title = "Customers";
    }
    public string Title { get; set; }
}

Now we need to declare what will be exported and where this exported class will fit, using the [Import] and [Export] attributes:

public class Menu
{
    [Import]
    private Module _module;

    public void OptionList()
    {
       Console.WriteLine(_module.Title);
    }
}

[Export]
public class Module
{
    public Module()
    {
        Title = "Customers";
    }
    public string Title { get; set; }
}

Note that the _module field in the Menu class is private – this doesn’t affect the composition. Now, we need to create our container and let it do its magic. In Program.cs put the following code:

static void Main(string[] args)
{
    var catalog = new AssemblyCatalog(Assembly.GetExecutingAssembly());
    var container = new CompositionContainer(catalog);
    var menu = new Menu();
    container.ComposeParts(menu);
    menu.OptionList();
    Console.ReadLine();
}

We have created an AssemblyCatalog (that searches the parts in the assembly – in our case, in the current assembly), then created the container that composes the parts after the menu is created. When the menu.OptionList() method is called, the module’s title is listed:

Getting more than one component

Now, you will say: but we have only one module listed. How do we do to have more than one? We must create a new interface IModule:

public interface IModule
{
    string Title { get; set; }
}

Our class will implement this interface and the export will tell that we are exporting the IModule interface:

[Export(typeof(IModule))]
public class Module : IModule
{
    public Module()
    {
        Title = "Customers";
    }

    public string Title { get; set; }
}

In order to match the parts, we must say that the imported part is also of IModule type:

public class Menu
{
    [Import]
    private IModule _module;
    public void OptionList()
    {
       Console.WriteLine(_module.Title);
    }
}

We execute the application and see that everything works like before. We can add the new modules:

[Export(typeof(IModule))]
public class Customer : IModule
{
    public Customer()
    {
        Title = "Customers";
    }
    public string Title { get; set; }
}

[Export(typeof(IModule))]
public class Product : IModule
{
    public Product()
    {
        Title = "Products";
    }
    public string Title { get; set; }
}

[Export(typeof(IModule))]
public class Supplier : IModule
{
    public Supplier()
    {
        Title = "Suppliers";
    }
    public string Title { get; set; }
}

We execute the application and… we get a ChangeRejectedException exception:
“More than one export was found that matches the constraint: ContractName IntroMEF.IModule“. MEF is complaining that we have many classes that export IModule.

The [Import] attribute allows only one export for the same interface. If there is more than one, this exception is thrown. When we want that many classes export the same interface, we must use the [ImportMany] attribute. To allow importing all the classes, we need to change the import a little, changing the attribute to [ImportMany] and the property type of the _module
field to IEnumerable<IModule>:

public class Menu
{
    [ImportMany]
    private IEnumerable<IModule> _modules;

    public void OptionList()
    {
        foreach (var module in _modules)
        {
           Console.WriteLine(module.Title);
        }
    }
}

We also changed OptionList to list all the modules. Now, when we execute the application, all the modules are found and listed:

Working with modules in different assemblies

You may be thinking: “this is easy to do – everything is in the same assembly. Doesn’t MEF allow modular and extensible apps?”. All the magic is in the container and in the catalog. We have  reated an AssemblyCatalog pointing to the current assembly, but we could do the same thing pointing to another assembly. You will answer: “this is still easy, I can add a reference to the other assembly where the modules are located. Where is the magic?”.

AssemblyCatalog is not the only catalog that we can use. We can use other catalog types, like the DirectoryCatalog, that finds parts in assemblies located in a specified folder.

Let’s change our project: in the solution, create a Portable Class Library and give it the name of IntroMEF.Interfaces. Choose the desired frameworks (use Framework 4.0 or higher) and delete the Class1.cs file. Add a new interface and put there the IModule interface, removing it from the main project. On the main project, add a reference to the interface project.

Create a new Class library project and give it the name of IntroMef.Modules. Add a reference to System.ComponentModel.Composition and remove the Class1.cs file. Add a
reference to IntroMef.Interfaces and move the classes Customer, Product and Supplier to the new project.

Now we need to tell that our parts are not only in the current assembly, but they can also be found in the current folder. For that we must compose two catalogs: one for the current assembly (for the imported parts) and another for the folder (for the exported parts). We will use an AggregateCatalog to compose both catalogs:

static void Main(string[] args)
{
    var catalog = new AggregateCatalog(
        new AssemblyCatalog(Assembly.GetExecutingAssembly()),
        new DirectoryCatalog("."));
    var container = new CompositionContainer(catalog);
    var menu = new Menu();
    container.ComposeParts(menu);
    menu.OptionList();
    Console.ReadLine();
}

We execute our application and nothing happens – no module is listed. That is due to the fact that we haven’t copied the modules assembly to the folder where the executable is located. Copy the assembly IntroMef.Modules to the executable folder, open a command window and execute the application again. Now the modules are recognized.

We didn’t need to add any references to the main project in the module library nor add a reference to the library in the main project. All we had to do is to copy the file to the executable folder. MEF found the modules when the assembly file was in the correct folder.

Creating a WPF project with MEF

Now you may be thinking: “that’s great, but I don’t create any console projects – how do I do a modular project using WPF?”. The answer is, in the same way we create a console application. To show that I am not lying, we will create a WPF project.

<Grid>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="120" />
        <ColumnDefinition Width="*" />
    </Grid.ColumnDefinitions>
    <ListBox Grid.Column="0" ItemsSource="{Binding Modules}" 
             DisplayMemberPath="Title" x:Name="LbxMenu"/>
    <ContentControl Grid.Column="1" Content="{Binding ElementName=LbxMenu, 
        Path=SelectedItem.Content}" />
</Grid>

We are adding a grid with two columns. In the first one we will add the found modules and in the second one, the contents for the selected module.  To make it work, we must have two properties in every module, Title, with the module’s title and Content, a UserControl with the contents of that module.

We need to create an interface for the modules. We will do in the same way we did before, creating a new library. Create a class library and name it WPFMef.Interfaces. Add the references to PresentationCore and WindowsBase. Remove the Class1.cs file and add a new interface IModule:

public interface IModule
{
    string Title { get; }
    UIElement Content { get; } 
}

Then create a new class library for the modules. Add a new class library and name it WPFMef.Modules. Add the references to WPFMef.Interfaces, System.ComponentModel.Composition, System.Xaml, PresentationCore, PresentationFramework and WindowsBase. Create the exported classes:

[Export(typeof(IModule))]
public class Customer : IModule
{
    public string Title
    {
        get { return "Customers"; }
    }

    public UIElement Content
    {
        get { return new CustomerList(); }
    }
}

[Export(typeof(IModule))]
public class Product : IModule
{
    public string Title
    {
        get { return "Products"; }
    }

    public UIElement Content
    {
        get { return new ProductList(); }
    }
}

[Export(typeof(IModule))]
public class Supplier : IModule
{
    public string Title
    {
        get { return "Suppliers"; }
    }

    public UIElement Content
    {
        get { return new SupplierList(); }
    }
}

The next step is to create the views that will be shown when the option is selected. Create three UserControls with a content similar to this one:

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="40" />
        <RowDefinition Height="*" />
    </Grid.RowDefinitions>
    <TextBlock Text="Customer List" HorizontalAlignment="Center" 
               VerticalAlignment="Center" FontSize="18"/>
    <ListBox x:Name="List" Grid.Row="1"/>
</Grid>

On the constructor of the view, add this code to add items to the ListBox:

public CustomerList()
{
    InitializeComponent();
    List.ItemsSource = Enumerable.Range(1, 100)
        .Select(n => "Customer " + n);
}

We have added a simple window that shows “Customer 1” to “Customer 100”, just to show what can be done. Our module library is finished.

Go back to the main project, add the references to the library WPFMef.Interfaces and to System.ComponentModel.Composition. Create a new class and give it the name of  MainViewModel. We will add there the code to initialize the container and the Modules property:

public class MainViewModel
{
    [ImportMany]
    public IEnumerable<IModule> Modulos { get; set; }

    public MainViewModel()
    {
        var catalog = new AggregateCatalog(
            new AssemblyCatalog(Assembly.GetExecutingAssembly()),
            new DirectoryCatalog("."));
        var container = new CompositionContainer(catalog);
        container.ComposeParts(this);
    }
}

We only need to associate the ViewModel to the View. In MainWindow.xaml.cs, add the following code:

public MainWindow()
{
    InitializeComponent();
    DataContext = new MainViewModel();
}

The project is ready and can be executed. When we execute it, we don’t see anything in the window. We forgot to copy the assembly with the modules again. Just copy the assembly to the executable folder and run the program again. Yesssss!

The data is shown when we select an option the content view at the right is changed.

If you don’t want to copy the project manually, you can change the project options, changing the output path for the modules, pointing to the executable path:

Conclusions

As you can see, MEF allows creating modular applications in an easy way that allows expanding our projects just by copying the dlls with the new modules. That works the same way in Windows Forms, WPF, Silverlight, Asp.Net and even Windows 8 (using NuGet). You have a standard way to create plug-ins that are not coupled, allow development done by many teams and adding or fixing modules with no need to recompile the whole project.

The full source code for this article is available in https://github.com/bsonnino/IntroMefEn and https://github.com/bsonnino/WPFMefEn

Introduction

In the previous article, “Testing the untestable with Fakes”, I have shown how to create unit tests for the legacy code that didn’t allow tests. With these tests in place we can give a step further to restructuring our code: using best practices on our project, creating code that can be easily maintainable in the future.

In this article we will restructure our code to use the MVVM pattern and Dependency injection. We will use here Unity, a framework created by Microsoft Patterns & Practices, for dependency injection.

Project architecture

Our project had all the code in code-behind and that makes creating tests a difficult task. Besides, that, it had a dependency on DateTime, that makes almost impossible to create reproducible tests.

The first step is to separate the model and the business rules from the view layer. This is done with the MVVM (Model-View-ViewModel) pattern. This pattern separates the presentation layer (View) from the data model (Model) using a binding layer, named ViewModel.

This design pattern makes extensive use of DataBinding in WPF/Silverlight/Windows Phone/Windows 8 and was created on 2005 by John Gossman, a Microsoft Architect on Blend team. If you want more information about this design pattern, you can check Josh Smith’s article on MSDN Magazine,  http://msdn.microsoft.com/en-us/magazine/dd419663.aspx.

The  ViewModel  is a class that implements the INotifyPropertyChanged interface:

public interface INotifyPropertyChanged
{
  event PropertyChangedEventHandler PropertyChanged;
}

It has just one event PropertyChanged that is activated when there is a change in a property. The Data binding mechanism present in WPF (and in other XAML platforms) subscribes this event and updates the view with no program intervention. So, all we need to do is to create a class that implements INotifyPropertyChanged and call this event when there is a change in a property to WPF update the view.

The greatest advantage is that the ViewModel is a normal class and doesn’t have any dependency on the view layer. That way, we don’t need to initialize a window when we test the ViewModel.

Creating the ViewModel

The first step for restructuring the program is to create the ViewModel. It is completely independent from the current project and doesn’t interfere with it.

We will use the same project that we’ve used in the previous article. Create a folder and name it ViewModel. In it, add a new class and name it MainViewModel:

class MainViewModel : INotifyPropertyChanged
{
    public event PropertyChangedEventHandler PropertyChanged;

    protected virtual void OnPropertyChanged([CallerMemberName] 
        string propertyName = null)
    {
        if (PropertyChanged != null) 
            PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}

Note that we’ve used the CallerMemberName attribute, from C# 5.0. It allows that the parameter propertyName from method OnPropertyChanged be filled with the name of the property that has called it, if we leave it blank. That means that if we have a property named TextData and do something like this:

public string TextData
{
    get { return _textData; }
    set
    {
        _textData = value;
        OnPropertyChanged();
    }
}

The compiler will fill the parameter with “TextData”, with no need that we explicitly fill it. This is excellent when we change the name of a property: if we had to pass the name for the OnPropertyChanged method and we forgot to change the parameter name, we would not have the change of the UI. Using the CallerMemberName atribute, this doesn’t happen.

Create a new property TextData, like we did above. Now, let’s create tests for this class. Go back to the test project and create a new class, calling it MainViewModelTests.cs. There, create a new test:

[TestClass]
public class MainViewModelTests
{
    [TestMethod]
    public void CreateMainViewModel_TextDataShouldHaveText()
    {
        var viewModel = new MainViewModel();
        Assert.AreEqual(
          "The current date is 01/01/2013 (Tuesday)", viewModel.TextData);
    }
}

When we execute this test, it doesn’t pass, because we didn’t create any code for assigning TextData.

We must create the code for the test to pass. Create the constructor of the MainViewModel class:

public MainViewModel()
{
    _textData = string.Format("The current date is {0:d} ({0:dddd})", 
       new DateTime(2013,1,1));
}

The test passes. We now refactor the code, creating a GetTextDate method:

public MainViewModel()
{
    _textData = GetTextDate();
}

private static string GetTextDate()
{
    return string.Format("The current date is {0:d} ({0:dddd})", 
      new DateTime(2013,1,1));
}

Our method is only valid for 1/1/2013. We must create another test for the other dates:

[TestMethod]
public void CreateMainViewModel_Date01022013_TextDataShouldHaveText()
{
    var viewModel = new MainViewModel();
    Assert.AreEqual("The current date is 01/02/2013 (Wednesday)", 
      viewModel.TextData);
}

This new test doesn’t pass. We need to go deeper – we need to change our program to retrieve the current date, but our test won’t work anymore (and won’t be reliable, as the date changes every day J), unless we use Fakes again. As we said before, this is not recommended. We need to remove the dependency of DateTime.

According to the book “Beautiful code”,  “all problems in computer science can be solved by another level of indirection”. That’s what we will do, create a level of indirection, an interface IDateTimeProvider, which will provide our dates. Create a folder and name it Interfaces and create a new interface IDateTimeProvider in it:

public interface IDateTimeProvider
{
    DateTime Now { get; } 
}

Implement this interface in the class SystemDateTimeProvider:

public class SystemDateTimeProvider : IDateTimeProvider
{
    public DateTime Now
    {
        get { return DateTime.Now; }
    }
}

We will pass this interface to the ViewModel using the Constructor Injection technique: we pass the interface to the constructor of the class and the interface is responsible for providing the current date. When we want the real data, we use the SystemDateTimeProvider class and when we want to test the code, we use a fake class created only for that.

The constructor of MainViewModel is changed to receive the new interface:

private readonly IDateTimeProvider _dateTimeProvider;

public MainViewModel(IDateTimeProvider dateTimeProvider)
{
    _dateTimeProvider = dateTimeProvider;
    _textData = GetTextDate();
}

With this change, we can alter the code of GetTextDate to use the provider:

private string GetTextDate()
{
    return string.Format("The current date is {0:d} ({0:dddd})", 
      _dateTimeProvider.Now);
}

Our tests need to be changed to pass the provider to the constructor of MainViewModel. We need to create a class that implements the interface and does what we want regarding to the date. In MainViewModelTests create the class FakeDateTimeProvider:

public class FakeDateTimeProvider : IDateTimeProvider
{
    private readonly DateTime _currentDateTime;

    public FakeDateTimeProvider(DateTime currentDateTime)
    {
        _currentDateTime = currentDateTime;
    }

    public DateTime Now
    {
        get { return _currentDateTime; }
    }
}

This class receives in the constructor the date we want as the current date. Now we can change our tests, passing an instance of this class:

[TestMethod]
public void CreateMainViewModel_TextDataShouldHaveText()
{
    IDateTimeProvider provider = new FakeDateTimeProvider(
       new DateTime(2013,1,1));
    var viewModel = new MainViewModel(provider);
    Assert.AreEqual("The current date is 01/01/2013 (Tuesday)", 
       viewModel.TextData);
}

[TestMethod]
public void CreateMainViewModel_Date01022013_TextDataShouldHaveText()
{
    IDateTimeProvider provider = new FakeDateTimeProvider(
       new DateTime(2013, 1, 2));
    var viewModel = new MainViewModel(provider);
    Assert.AreEqual("The current date is 01/02/2013 (Wednesday)",
       viewModel.TextData);
}

Our tests pass with no problems and we have removed the dependency to DateTime. The next step is to bind the ViewModel to the View. This is done setting the DataContext property of the view to an instance of the viewmodel. One way to do that is to put the following code on the constructor of the view:

public MainWindow()
{
    InitializeComponent();
    IDateTimeProvider provider = new SystemDateTimeProvider();
    DataContext = new MainViewModel(provider);
}

This works fine, but it has two problems:

• We have to create an instance of SystemDateTimeProvider to pass it to the constructor of the viewmodel.
• The viewmodel doesn’t work at design time, thus making it difficult to design the UI.

To overcome these two problems, we will use the ViewModelLocator technique, a class that will use Dependency Injection to locate and instantiate our viewmodels. We will use a Dependency injection framework to do it. There are many good ones in the market, most of them free: Castle Windsor, Autofac, StructureMap and Ninject are very good, but we will use Unity, a framework created by Microsoft Patterns and Practices.

We can install it using Nuget. On the solution Explorer, right-click the References node and choose “Manage Nuget Packages”. Search for Unity and install it:

Unity works in the following way: we register the interfaces with the associated concrete classes in the container and then we call the Resolve method to return the classes instances – all dependencies are resolved and the class instance is returned. There is no need to register the concrete classes if Unity can create them (by having a default parameterless constructor or with dependencies that can be resolved).

For example, the register phase in our classes would be:

_container = new UnityContainer();
_container.RegisterType<IDateTimeProvider, SystemDateTimeProvider>();

To get an instance of MainViewModel, we use something like:

_container.Resolve<MainViewModel>();

We do not need to register the MainViewModel class, because Unity can resolve all dependencies with the registered interfaces. Now, we can create a new class on the folder ViewModel, named ViewModelLocator:

private readonly UnityContainer _container;

public ViewModelLocator()
{
    _container = new UnityContainer();
    _container.RegisterType<IDateTimeProvider, SystemDateTimeProvider>();
}

public MainViewModel Main
{
    get { return _container.Resolve<MainViewModel>(); }
}

We register the IDateTimeProvider interface, associating it to the SystemDateTimeProvider class and create a property named Main that returns an instance of MainViewModel. To use this class, we add an instance to the Resources section of App.xaml. In App.xaml, add this code:

<Application.Resources>
     <viewModel:ViewModelLocator x:Key="Locator"/>
</Application.Resources>

Add the namespace for the ViewModelLocator in the Application class declaration:

<Application 
    x:Class="FakesTest.App"
    xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
    xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
    xmlns:viewModel="clr-namespace:FakesTest.ViewModel"
    StartupUri="MainWindow.xaml">

Finally, in MainWindow, set the property DataContext to the property Main of the ViewModelLocator and bind the property Text of the TextBlock to the property TextData of the ViewModel:

<Window x:Class="FakesTest.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        Title="MainWindow" Height="350" Width="525"
        DataContext="{Binding Source={StaticResource Locator}, Path=Main}">
    <Grid>
        <TextBlock x:Name="TxtDate" Text="{Binding TextData}"/>
    </Grid>
</Window>

When we do that, the current date data appears at design time:

We can then remove the code behind and our code in MainWindow.xaml.cs stays like that:

public partial class MainWindow
{
    public MainWindow()
    {
        InitializeComponent();
    }
}

Execute the program and observe that it behaves exactly in the same way as it did before. When we execute our tests, we see that they pass, but the first test (the one we’ve created in the prior article) doesn’t pass:

Test method FakesTest.Tests.MainWindowTests.CreateWindow_TextBlockHasCurrentDate threw exception: 
System.Windows.Markup.XamlParseException: 'Provide value on 'System.Windows.StaticResourceExtension' threw an exception.' Line number '5' and line position '9'. ---> System.Exception: Cannot find resource named 'Locator'. Resource names are case sensitive.

This is due to the fact that we have the dependency between the View and the ViewModelLocator. As we wanted to remove the dependency of Fakes, we can ignore this test, adding the Ignore attribute (we could remove this test, as it doesn’t make sense anymore, but I decided to leave it, as a reminder of the old times that should never come back J):

[Ignore]
[TestMethod]
public void CreateWindow_TextBlockHasCurrentDate()
{
    using (ShimsContext.Create())
    {
        ShimDateTime.NowGet = () => new DateTime(2013,1,1);
        var window = new MainWindow();
        var mainGrid = (Grid)window.Content;
        var textBlock = (TextBlock) mainGrid.Children[0];
        Assert.AreEqual("The current date is 01/01/2013 (Tuesday)",
           textBlock.Text);
    }
}

Conclusions

We finished our restructuring. Our code, once dependent of the Window and to DateTime, making it almost impossible to test, is now detached and 100% testable.

For that, we restructured the code using a ViewModel and Dependency Injection that resolves our dependencies in an automatic way, giving us a bonus of having the data at design time. We don’t need to use Fakes anymore and the program is ready for new updates.

Introduction

Sometimes you must do some changes on legacy programs that were not built using good development practices. At that time, our first reaction is to run away from that: the probability of having problems is too high and touching the source code is almost impossible – we are working on a castle of cards, where even the slightest move can bring everything down.

The idea of refactoring (or even rewrite) the code comes from a long time, but where is the time to do that? All projects are late and that’s not a priority, its working, no? Why touch on that?

We can make the situation a little better by creating unit tests for the changes we must do, but how to do that? The program is full of dependencies, the business rules are mixed with the views, and the methods are long and complicated.

The best we could do are integration tests, that are difficult to implement and slow to execute, they will be abandoned very soon. What to do now? The solution is at hand, Microsoft implemented a Microsoft Research’s project, named Moles, and put it in Visual Studio 2012 with the name of Fakes, so we can create test for anything, including .Net Framework classes.

With Fakes we can create unit tests that run fast and don’t depend of anything, nor operating system, machine or database. Here I must do a note: although Fakes can test almost anything, that’s not an excuse to relax our coding style – you must use good programming practices on the new code and do not rely on Fakes to simulate dependencies that should not exist. When you are creating new code, try to do it in a way that you don’t need Fakes, use it only where that is really needed.

The problem

To show how to use Fakes, we will create a small WPF project that has a window with a TextBlock:

 <Window x:Class="FakesTest.MainWindow"  
     xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"  
     xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"  
     Title="MainWindow" Height="350" Width="525">  
   <Grid>  
     <TextBlock x:Name="TxtDate"/>  
   </Grid>  
 </Window>  

When the window is initialized, the TextBlock is fed with the current date:

 public partial class MainWindow  
 {  
   public MainWindow()  
   {  
     InitializeComponent();  
     TxtDate.Text = string.Format(  
      "The current date is {0:d}", DateTime.Now);  
   }  
 }  

We should change this code to put the weekday in the TextBlock, like in “The current date is 8/2/2013 (Friday)”. We want to use best practices and will create unit tests for the project. But how to do it? The code is mixed with the View and has a dependency on DateTime, a .Net Framework class.

Creating the test project

The first step is to create the test project. On the Solution Explorer, select the solution and right click it, selecting Add/New Project. Select Test/Unit Test Project and call it FakesTest.Tests. Add to it a reference to our project. Rename the UnitTest1.cs class to MainWindowTests.cs.

Here starts our problem: we want to test what is being shown in the TextBlock. For that, we must create a window, initialize it and look at its content. Not an easy task to do with unit tests.

 Here comes Fakes to rescue. On the test project, on the references, select the reference to the main project and select Add Fakes Assembly. A new reference to FakesTest.Fakes is added – this reference will create all fakes for the window and its componentes. To use it on our tests, we must add the references to System.Xaml, PresentationCore, PresentationFramework and WindowsBase.

 The next step is to create a fake for the DateTime class. Select the System assembly in the references and right click it, selecting Add Fakes Assembly. Now that we have all our environment “virtualized”, we can start creating tests.

To use the components created by Fakes we must surround the calls in a context, with the keyword Using, using a ShimsContext:

 using (ShimsContext.Create())  
 {  
   ….  
 }  

Inside the context, we must tell the behavior of the fake DateTime class, when the method Now will be called:

 ShimDateTime.NowGet = () => new DateTime(2013,1,1);  

To access the DateTime class created by Fakes, we must use the ShimDateTime class. The line above tells us that when the getter of the Now property is called (NowGet), it must return 1/1/2013. From now on, the test becomes exactly the same as any other unit test:

 [TestMethod]  
 public void CreateWindow_TextBlockHasCurrentDate()  
 {  
   using (ShimsContext.Create())  
   {  
     ShimDateTime.NowGet = () => new DateTime(2013,1,1);  
     var window = new MainWindow();  
     var mainGrid = (Grid)window.Content;  
     var textBlock = (TextBlock) mainGrid.Children[0];  
     Assert.AreEqual("The current date is 01/01/2013",textBlock.Text);  
   }  
 }  

We have created the window and verified if the TextBlock has the date we have passed on the fake. When we execute the tests with Ctrl+R+T, we see that the test passes. We are covered here, and we can make the changes we need on our code.

Changing the program

As we already have the test, we can change it for the new feature we want:

 [TestMethod]  
 public void CreateWindow_TextBlockHasCurrentDate()  
 {  
   using (ShimsContext.Create())  
   {  
     ShimDateTime.NowGet = () => new DateTime(2013,1,1);  
     var window = new MainWindow();  
     var mainGrid = (Grid)window.Content;  
     var textBlock = (TextBlock) mainGrid.Children[0];  
     Assert.AreEqual(  
      "The current date is 01/01/2013 (Tuesday)",textBlock.Text);  
   }  
 }  

We have made the change on the test but not on the code. If we run our test now, it will fail:

 Assert.AreEqual failed. Expected:<The current date is 01/01/2013 (Tuesday)>. Actual:< The current date is 01/01/2013>.  

We must change the code:

 public MainWindow()  
 {  
   InitializeComponent();  
   TxtDate.Text = string.Format(  
    "The current date is {0:d} ({0:dddd})", DateTime.Now);  
 }  

When we execute the test, it passes – our change is complete and working. To complete the Red-Green-Refactor cycle from TDD, we can refactor the code, extracting the function from where we set the TextBlock:

 public MainWindow()  
 {  
   InitializeComponent();  
   TxtDate.Text = GetTextDate();  
 }  
 private static string GetTextDate()  
 {  
   return string.Format(  
    "The current date is {0:d} ({0:dddd})", DateTime.Now);  
 }  

We run the tests and they still pass. The change is finished.

Conclusions

As we can see, Fakes helps a lot when we have legacy code that, for its dependencies, don’t allow creating unit tests in an easy way. What we have done here is to simulate the creation of a window and assign a value to a TextBlock, passing the current date with no special arrangement.

We are not advocating using this resource always – you should use Fakes only as the last resource, when the code is already there and there is not an easy way to break it. It can be used as a starting point for the real refactoring of the program: in this case, we must remove the window dependencies using the MVVM pattern and also from the System.DateTime, using some kind of wrapper interface (that we could call as IDateTimeProvider), but this is a subject for another article!

On the two last posts, I’ve showed how to animate a transition using code. The first post showed how to animate the transition using code behind, creating the animation using code. The second post showed how to use components to ease these transitions. Although the use of components is a good alternative to create the animations using code, it still has some disadvantages:

• You must add a reference to the component assembly or include its code in the project
• It can have bugs – there may be many users of the components, but they still may have bugs. If they are open source with code available, you can still debug it, but is not always easy to debug such a component.
• It can be outdated. With new versions of WPF and Silverlight, an old component may not work in the new versions.

So, we will see a new option to animate the transitions, with no code. You may be asking : “How is that, no code?”. Yes, WPF 4 (or 3.5, using the WPF Toolkit) and Silverlight have a resource that don’t need C# or VB code to animate transitions: Visual States. With Visual States, you define the state of your control in many situations and change between them with no need of code. Everything is done in XAML.

For this project, we won’t use Visual Studio. The creation of Visual States is easier in Blend. Open Blend and create a new WPF project.

In this project, add a row in the main grid, at the bottom of the window with 40 pixels of height. On this row, add a button with the property Content set to Hide. On the top row of the grid, add another grid, with red background. On the project panel choose the States tab. It should be empty.

Click on the first button on the top toolbar in the tab to add a new group state. Change its name to GridStates. Click on the second button of the GridStates toolbar to add a new state and change its name to Visible. Add another state and change its name to Hidden.

You should note that the default transition time (shown in front of the Default Transition text) is 0s.

Change this time to 1. Also change the Easing Function to CubicInOut, clicking the second button.

Looking at the image above, you can see we are in recording mode, recording the Hidden state. When we select a state in the states panel, all changes that we make in the layout are recorded for this state. So, we can change the appearance of our controls just by switching states. The state Visible is our default state. On the Hidden state we will hide our grid. The transition is done when we change from one state to another.

Select the grid and change the property RenderTransform X to –625, the property Opacity to 0 and the property Visibility to Collapsed. That way, the grid will move to the left, while it’s made transparent. Our states are ready. We could change between states using code behind, with this code on the button click event:

private void button_Click(object sender, System.Windows.RoutedEventArgs e)
{
  VisualStateManager.GoToElementState(LayoutRoot, "Hidden", true);
}

But that way, we would be on the same situation of the previous post, with code behind. Besides that, I have said that we would not use code!

Blend has a very interesting resource to execute actions with no code: Behaviors. Behaviors are custom actions that act on the components, with no need of code to execute them (in fact, someone needs to write code to create a behavior, but once it’s created, you just need to drag it to a component to use it). Blend comes with many predefined behaviors. To use them you should go to the Assets panel and select the Behaviors option.

We will use the GoToStateAction behavior. We drag this behavior to a component, then set the event that will trigger it and what is the new state that must be set when the event is triggered. Select the GoToStateAction and drag it to the button. A GoToStateAction is added to the button on the object inspector.

On the property editor we will configure the action.

The trigger is already set: we want to activate the action when the button Click event is triggered. We must only set the state we want to select when the button is clicked. For that, we must set the StateName property to Hidden.

Our application is ready. When we execute it and click on the button, the transition occurs and moves the grid to outside. And all that with no lines of code!

We will make a small change to give more functionality to our application. Change the editor visualization to Split by clicking on the third button of view change.

With that, we can change the XAML code directly and change our button. We want it to be a ToggleButton. For that you must change the XAML component, changing its type from Button to ToggleButton:

<ToggleButton x:Name="button" Content="Hide" Grid.Row="1" HorizontalAlignment="Center" 
    VerticalAlignment="Center" Width="65" Height="25">
  <i:Interaction.Triggers>
    <i:EventTrigger EventName="Click">
      <ei:GoToStateAction StateName="Hidden"/>
    </i:EventTrigger>
  </i:Interaction.Triggers>
</ToggleButton>

The ToggleButton may be checked or not. We will show the Hidden state when it’s checked and the Visible state when it’s unchecked.

We must change the event that activates the Hidden state. On the object inspector, select the GoToStateAction and change the property  EventName to Checked. On the Assets tab, select another GoToStateAction and drag it to the button. Set the property EventName to  Unchecked and the property StateName to Visible. Run the program.

Now we have an animation to hide the grid when the button is checked and another to show the grid when the button is unchecked. Easy, no?

Here we could see the amount of resources we have available to create states and make them active. Everything is done visually, with no need of code. We still haven’t finished our journey, we still have other ways to animate transitions, but that is a subject for another post. See you there!

In the last post we saw how to animate a transition using code. As I said, I don’t think that is the best solution, because we must use code behind, something not easy to maintain. We could refactor code, creating a new class for the animation and use it. That would bring a little more separation, but we would have to still use code behind.

In this second part, we will use a different approach: third party components. We can use several components, like Kevin Bag-O-Tricks (https://github.com/thinkpixellab/bot), FluidKit (http://fluidkit.com), Silverlight Toolkit (http://silverlight.codeplex.com – only for Silverlight), or Transitionals (http://transitionals.codeplex.com).

We will use here Transitionals, for WPF. If we want to do animations for Silverlight, we should choose another component. Its use is very simple: after downloading the component and adding a reference in the project to the Transitionals.dll assembly, we must add a TransitionElement component in the place where we want the animation, configure the animation and add a content to the component. When the content is changed, the transition is activated.

Let’s create our transition project. Create a new WPF project and add a reference to Transitionals.dll. Then, add a TransitionElement to the main grid:

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition Height="*" />
        <RowDefinition Height="40" />
    </Grid.RowDefinitions>
    <transc:TransitionElement x:Name="TransitionBox">
        <transc:TransitionElement.Transition>
            <transt:TranslateTransition  StartPoint="1,0" EndPoint="0,0" Duration="0:0:1"/>
        </transc:TransitionElement.Transition>
    </transc:TransitionElement>
    <Button Width="65" Grid.Row="1" Content="Hide" Margin="5" Click="Button_Click" />
</Grid>

We must declare the namespaces for the TransitionElement and for the TranslateTransition in the main window:

<Window x:Class="WpfApplication2.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:transc="clr-namespace:Transitionals.Controls;assembly=Transitionals"
        xmlns:transt="clr-namespace:Transitionals.Transitions;assembly=Transitionals"
        Title="MainWindow" Height="350" Width="525">

The next step is to add content to the TransitionElement:

<transc:TransitionElement x:Name="TransitionBox">
    <transc:TransitionElement.Transition>
        <transt:TranslateTransition  StartPoint="1,0" EndPoint="0,0" Duration="0:0:1"/>
    </transc:TransitionElement.Transition>
    <Grid Background="Red" />
</transc:TransitionElement>

The button click event handler changes the content of the TransitionElement and activates the transition:

private void Button_Click(object sender, RoutedEventArgs e)
{
    TransitionBox.Content = new Grid() {Background = Brushes.Blue};
}

That way, the code is simpler, we just need to change the content of the element. Besides that, the Transitionals component has a lot of transition types, and we can set them in many ways. For example, the TranslateTransition has the properties StartPoint and EndPoint, saying where the transition starts and ends. To do it from left to right, StartPoint should be –1,0 and EndPoint, 0,0. From top to bottom, StartPoint should be 0,-1 and EndPoint, 0, 0. We can even do a diagonal transition using 1,1 and 0,0.

Eliminating Code Behind

One thing that can be improved here is the elimination of code behind, using the MVVM pattern. We will use the MVVM Light framework, that you can get at http://galasoft.ch or by installing it directly using NuGet, an add-in to Visual Studio to ease download and installation of libraries and tools in Visual Studio. If you still don’t have NuGet, go to http://nuget.org and download it.

Once you have installled NuGet, you can click with the right button in References in the Solution Explorer and select “Manage Nuget Packages”. Fill the search box with “mvvm” and install the MVVM Light package:

This installs MVVM Light, adds the required references and creates a folder named ViewModel, with two files, MainViewModel.cs and ViewModelLocator.cs. MainViewModel.cs is the ViewModel related to the main window and ViewModelLocator is a ViewModel locator.

In MainViewModel.cs you should add a property of type ViewModelBase, which will contain the ViewModel related to the View of the component content:

private ViewModelBase content;

public ViewModelBase Content
{
    get { return content; }
    set
    {
        conteudo = value;
        RaisePropertyChanged("Content");
    }
}

Next, we will create two ViewModels, related to our views. The two ViewModels are very similar and have only one property:

public class ViewModelA : ViewModelBase
{
    private string text;

    public string Text
    {
        get { return text; }
        set
        {
            text = value;
            RaisePropertyChanged("Text");
        }
    }
}

public class ViewModelB : ViewModelBase
{
    private string text;

    public string Text
    {
        get { return text; }
        set
        {
            text = value;
            RaisePropertyChanged("Text");
        }
    }
}

Then create in the Solution Explorer a folder named View and put there two UserControls, each one with a Grid and a TextBlock:

<UserControl x:Class="WpfApplication2.View.ViewA"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" 
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008" 
             mc:Ignorable="d" 
             d:DesignHeight="300" d:DesignWidth="300">
    <Grid Background="Red">
        <TextBlock Text="{Binding Text}" FontSize="36" />
    </Grid>
</UserControl>

To eliminate code behind, we must bind the property Content of the TransitionElement with the property Content of the ViewModel:

<transc:TransitionElement x:Name="TransitionBox" Content="{Binding Content}">
    <transc:TransitionElement.Transition>
        <transt:TranslateTransition  StartPoint="1,0" EndPoint="0,0" Duration="0:0:1"/>
    </transc:TransitionElement.Transition>
</transc:TransitionElement>

and eliminate the button click, replacing it with a Command:

<Button Width="65" Grid.Row="1" Content="Esconde" Margin="5" Command="{Binding HideCommand}" />

The HideCommand property is defined in MainViewModel:

private ICommand hideCommand;
public ICommand HideCommand
{
    get { return hideCommand ?? (hideCommand = new RelayCommand(ChangeContent)); }
}

private void ChangeContent()
{
    Content = content is ViewModelA ? 
        (ViewModelBase)new ViewModelB() {Text = "ViewModel B"} : 
        (ViewModelBase)new ViewModelA() {Text = " ViewModel A"};
}

Finally we must set the DataContext for the main View:

<Window x:Class="WpfApplication2.MainWindow"
        xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
        xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
        xmlns:transc="clr-namespace:Transitionals.Controls;assembly=Transitionals"
        xmlns:transt="clr-namespace:Transitionals.Transitions;assembly=Transitionals" 
        Title="MainWindow" Height="350" Width="525"
        DataContext="{Binding Source={StaticResource Locator}, Path=Main}">

When we execute the program we have something similar to this:

The view isn’t shown, just the content’s class name. That is expected, as the property Content is of type ViewModelBase and its presentation is made by the method ToString(). We could have put the view as content, but this goes against the MVVM pattern: the ViewModel must not know about the View. A solution to show the View using the ViewModel as content is to use a resource available in WPF or in Silverlight 5: implicit Data Templates. In an implicit DataTemplate, we don’t set the Key property when declaring the Template, we only set its DataType. With that, WPF and Silverlight use this DataTemplate every time they must render some content of that type.

We declare the DataTemplates in the Windows’s resources section:

<Window.Resources>
    <DataTemplate DataType="{x:Type ViewModel:ViewModelA}" >
        <View:ViewA />
    </DataTemplate>
    <DataTemplate DataType="{x:Type ViewModel:ViewModelB}" >
        <View:ViewB />
    </DataTemplate>
</Window.Resources>

Now, when we execute the program, we have the transition between the two views, with no code behind.

Conclusion

When we use components to animate transitions, we have the possiblity to create very complex transitions in an easy way, we only have to change the content of the control.

We also saw how to remove code from the code behind, adding it to a ViewModel, making it easier to maintain and allowing better testability. As a bonus, we saw how to use implicit DataTemplates and how to relate a View to a ViewModel with no need of code. This resource is only available on WPF and Silverlight 5.

Although you can think it doesn’t worth the effort (we eliminated just one line of code, trading it with two ViewModels, two Views and a new MVVM component), my intent here was to show you other resources, like using MVVM instead of code behind and how to use new features, like the implicit DataTemplate. In a larger application, that requires more work, these changes are justified.

These are not the only ways to do control transitions. On the next articles, we will see other ways. See you then!