edventuro.us

SoC, DI, IoC, WTF? A basic introduction to Dependency Injection with Ninject

Ed — Sat, 03 Apr 2010 13:55:06 +0000

The latest TLA (Three Letter Acronyms) du jour seem to be SoC, DI, and IoC. What do these stand for and why should you care about them?

Consider the following (very) simple console application:

Code Snippet

using System;
 
namespace TightlyBoundTestApp
{
    public class Program
    {
        static void Main(string[] args)
        {
            // Load up a customer
            Customer c = new Customer();
 
            // Logging should have written a message
            c.Log();
 
            Console.ReadKey();
        }
    }
 
    public class Customer
    {
        private Logger logger;
 
        public Customer()
        {
            logger = new Logger();
        }
 
        public void Log()
        {
            logger.LogMessage("This should be logged");
        }
    }
 
    public class Logger
    {
        public void LogMessage(string message)
        {
            Console.WriteLine("Log: " + message);
        }
    }
}

In this sample application, we have a Customer class which (for example purposes) only has a single method: Log, which allows it to log a message. We might use this to keep track of the transactions done by a customer so we have an audit trail for example. The logging happens by calling the LogMessage method on an instance of the Logger class which the Customer class created in its constructor.

In our entry point to the program, we create a new instance of our Customer class, and tell it to log a message. If we run this, a log message will be printed to the console, then the program will exit once we press a key.

So, it all works okay, but there a few problems which may cause issues for us down the track. We have made our Customer class depend on our Logger class. What happens when we want to create unit tests for our Customer class? We would also have to consider our Logger class as they are tightly coupled.

This violates the first of our TLAs: Separation of Concerns (SoC). "Separation of Concerns is the process of separating a computer program into distinct features that overlap in functionality as little as possible. A concern is any piece of interest or focus in a program.” – Wikipedia

How do we go about achieving this separation then? Instead of having our Customer class depend on a concrete implementation of a Logger class, we could change it to interact with an interface instead. The principle behind this is known as Dependency Inversion – "High-level modules should not depend on low-level modules. Both should depend on abstractions." – Wikipedia.

By changing the Customer class to interact with an ILogger interface, we could provide one implementation in our Application, and a completely different one in our tests. This design technique is known as Programming to Contract.

So, let’s start refactoring our sample program by creating an interface for the Logger:

Code Snippet

public interface ILogger
{
    void LogMessage(string message);
}

And then we can implement that interface in our Logger class:

Code Snippet

public class Logger : ILogger
{
    public void LogMessage(string message)
    {
        Console.WriteLine("Log: " + message);
    }
}

And in our test project we could implement it differently, maybe keep a reference to the last message logged so we can check it in our tests for example:

Code Snippet

public class TestLogger : ILogger
{
    public string LastMessage { get; set; }
 
    public void LogMessage(string message)
    {
        LastMessage = message;
    }
}

Great, so we are now programming to contract and have an interface for our logger. But how does our Customer class know which concrete implementation of the ILogger to use? If we keep the following code:

Code Snippet

public Customer()
{
    this.logger = new Logger();
}

We’re no better off that where we were originally, as the Customer class is still using a concrete implementation of the Logger class. What we need to do instead is to tell which implementation of the ILogger to use. There’s a few different ways to do this. The simplest way to do this is to provide the implementation in the constructor, by changing our Customer class to the following:

Code Snippet

public class Customer
{
    private ILogger logger;
 
    public Customer(ILogger logger)
    {
        this.logger = logger;
    }
 
    public void Log()
    {
        logger.LogMessage("This should be logged");
    }
}

Now when we instanciate our Customer in the main program, we pass in the implementation of the ILogger we wish to use at that point, like so:

Code Snippet

// Create a new customer
Customer c = new Customer(new Logger());

And in our tests, we could simply pass in an alternative implementation:

Code Snippet

// Create a new customer with a test logger
Customer c = new Customer(new TestLogger());

This is the simplest form of the next of our TLAs: Dependency Injection (DI) – "a technique for supplying an external dependency (i.e. a reference) to a software component – that is, indicating to a part of a program which other parts it can use" – Wikipedia.

You could also use a Factory / Service Locator pattern, but we’re going to skip past that and jump straight into the last of our TLAs: Inversion of Control (IoC), specifically IoC Containers. Containers provide a centralised place to manage dependencies. Think of a container as a dictionary which maps interfaces to implemented types. In other words, it resolves dependencies.

While you can code a fairly simple DependencyResolver class using Generics (see James Kovacs’ article for one such example), there are numerous fully fledged implementations in the .Net world. Some popular options are: StructureMap, Castle Windsor, Microsoft’s Unity, and Ninject. There are many more out there, some of which are listed on Scott Hanselman’s blog.

The rest of this post will focus on Ninject, as I feel it is the simplest to illustrate the concepts of DI without getting too bogged down. A subsequent post will revist the example using Unity instead to contrast the differences. The important thing is to remember the concepts behind these different tools are the same, so don’t get too hung up on which is ‘best’.

Ninject

You can download Ninject from here.

There are two main methods you’ll use with Ninject, Bind and Get.

‘Bind’ is used to map the interfaces to the implemented types, i.e. if I ask for an , give me a . The binding is usually set up in a module which extends the NinjectModule class. Binding uses generics to provide a fluent interface: Bind<YourInterface>().To<YourConcreteImplementation>(); In our example program it looks like this:

Code Snippet

public class StandardModule : NinjectModule
{
    public override void Load()
    {
        Bind<ILogger>().To<Logger>();
    }
}

‘Get’ is used to actually retrieve your concrete implementations with all their dependencies ‘injected’ into them. Get is a method on the Kernel. The ‘Kernel’ is your container, and is usually an instance of the StandardKernel which is instanciated with the Module that you setup your bindings in as above.

Code Snippet

IKernel kernel = new StandardKernel( new StandardModule() );
 
// Get a new customer from our container
Customer c = kernel.Get<Customer>();

So, we set up our Kernel with a reference to our module which is binding any request for an ILogger to our Logger class. We then ‘Get’ our Customer class from the Kernel. But hang on, our Customer class isn’t implementing an interface, why do we need to get it using the Kernel? Couldn’t we just instanciate it as usual?

This threw me a little when I first started using Ninject until I realised that unless you get an object via the Kernel, any dependencies that object has will NOT be injected.

So, that’s why we use kernel.Get to retrieve our Customer. By using the kernel, it ensures that the dependency the Customer has on ILogger is injected using the binding we setup in our StandardModule.

Instead of using the constructor to do the injection, Ninject also allows us to use the [Inject] attribute to mark up Properties, Methods, and Fields to be injected. See: http://ninject.codeplex.com/wikipage?title=Injection%20Patterns&referringTitle=Dependency%20Injection%20With%20Ninject for more details.

So, we could change our Customer class to the following:

Code Snippet

public class AlternativeCustomer
{
    [Inject]
    public ILogger CustomerLogger {get; set;} // Injected automagically when required by Ninject, providing the class is instantiated via Kernal.Get
 
    public AlternativeCustomer()
    {
        // No longer need to instanciate a logger in the constructor as it is injected when required.
    }
 
    public void Log()
    {
        CustomerLogger.LogMessage("This should also be logged");
    }
}

By marking the CustomerLogger property with the [Inject] attribute, whenever it is required (in the Log method for instance), Ninject will resolve the dependency, in this case mapping our ILogger to our Logger class as defined in the StandardModule.

In our tests then, we could create a different set of mappings by binding our ILogger to a different implementation, like our TestLogger. Dependency Injection and Mocking go together very well, and there is an extension class for Ninject called Ninject.Moq which allows you to bind directly to a mock, e.g:

Code Snippet

Bind<ILogger>().ToMock<ILogger>();

Hopefully that has helped you to see the power of Dependency Injection. Take a look at the attached solution to see the original tightly coupled application, the decoupled application using constructor injection, and then the same application using Ninject, along with a simple unit test using Ninject.

Sample Solution:

NinjectTestApp.zip

References:

Tame Your Software Dependencies for More Flexible Apps
http://msdn.microsoft.com/en-us/magazine/cc337885.aspx

First Steps into Dependency Injection with Ninject
http://adventuresdotnet.blogspot.com/2009/08/first-steps-into-dependency-injection.html

Ninject website
http://ninject.org

Good video tutorial on Ninject:
http://tekpub.com/view/concepts/0

Porting a WPF App with the Model-View-ViewModel Design Pattern to Silverlight 4

Ed — Tue, 23 Mar 2010 18:07:27 +0000

Tim Heuer wrote glowingly about Josh Smith’s new book ‘Advanced MVVM‘ on his blog recently (http://timheuer.com/blog/archive/2010/03/04/advanced-mvvm-book-for-silverlight-wpf.aspx), so I decided to check it out.

I was reading through the comments, and saw that Josh recommended checking out an article on MSDN he’d written in Feb 2009 entitled: "WPF Apps With The Model-View-ViewModel Design Pattern" and get a firm grounding in that before moving on to his new book. This seemed like a good idea, so I decided I’d try migrating the WPF example app in the article over to Silverlight 4 as a way of trying out some of the new features like support for Commands, IDataErrorInfo support, etc.

In line with the Pareto principle, most of the migration went very smoothly and swiftly and then there were a few snags which ended up taking the bulk of the time to resolve. I’ve outlined these issues and their resolutions below in the hope that it helps someone doing something similar in future. The full completed Silverlight 4 solution is also included at the bottom of the post.

Silverlight version vs WPF version

Issue One: No CollectionViewSource.GetDefaultView in Silverlight

Josh uses the CollectionViewSource.GetDefaultView method in the SetActiveWorkspace method to retrieve the default view of the Workspaces ObservableCollection, and then move the current item in that view to the workspace which has been passed in, using MoveCurrentTo. This is used when one of the Hyperlinks in the left hand pane is clicked, which results in a new tab being added to the workspaces tab control. MoveCurrentTo is used to set this latest item as the CurrentItem, which results in that tab being selected in the tab control.

Unfortunately Silverlight 4 doesn’t implement the GetDefaultView method on CollectionViewSource, so we have to retrieve a view from CollectionViewSource in an alternative way. I did this by changing the SetActiveWorkspace method to take an additional parameter in the form of an instance of a CollectionViewSource. The view is then retrieved using the View property of this instance, and the rest of the code works as expected.

To allow for an instance of a CollectionViewSource to be passed in, we define a public property called WorkspacesViewSource, and then initialise it in the constructor of the ViewModel, and set the instance’s Source property to be the Workspaces ObservableCollection.

This necessitates further changes though, as we now need to bind our Workspaces tab control ItemsSource property directly to the View property of our public CollectionViewSource: WorkspacesViewSource. We can do this in the Xaml of the TabControl using the syntax: ItemsSource="{Binding WorkspacesViewSource.View}". We now also need to raise the property changed event for WorkspacesViewSource when a workspace is added or removed, so we call our base.OnPropertyChanged method in the OnWorkspacesChanged event.

While this worked, it was not enough to get the Workspace tabs displaying in the tab control, due to the next problem…

Issue Two: Unable to cast object of type ‘MVVMSilverlightDemoApp.ViewModel.AllCustomersViewModel’ to type ‘System.Windows.Controls.TabItem’.

When a new workspace is added to the collection and the ItemsSource for the Workspaces tab control is refreshed, an ArgumentException was being thrown: Unable to cast object of type ‘MVVMSilverlightDemoApp.ViewModel.AllCustomersViewModel’ to type ‘System.Windows.Controls.TabItem’.

This is being throw by the OnItemsChanged event in the TabControl class. Luckily, we can look at the source code of this class as it is in the Silverlight Toolkit. In the OnItemsChanged event, we see that the TabControl casts each item in its ItemSource as a TabItem, and then if it fails the cast, it throws the ArgumentException.

There were a couple of options to solving this. We could subclass the TabControl and override the OnItemsChanged event to deal with our workspace items better. I started doing this, but it started rapidly escalating as there were a few Private and Internal methods and variables that the event utilised, so it began to look like I’d need to duplicate and modify the entire TabControl class, along with its dependant classes. Entirely possible, given that the source is all open, but I thought this was starting to diverge from the point of the exercise.

A quick search for the issue came up with a post on the Silverlight forums where it was mentioned that "TabControl doesn’t override PrepareContainerForItemOverride, so it won’t automatically wrap your data source in TabItems". The post suggested that the solution was to use a value converter on the ItemSource to turn each item into a TabItem.

I thought I’d try overriding the PrepareContainerForItemOverride method in my subclassed TabControl first, however this didn’t change the ArgumentException in the OnItemsChanged event, so I added a converter: WorkspacesTabConvertor.

This worked, in that the TabControl now displayed a tab for each item, and it was rendered correctly. However, each time the ItemsSource was updated (by adding or removing a workspace) all the tabs were recreated, which meant any selections in the AllCustomersView or data entered in a CustomersView were lost.

I settled on a workaround where I created a custom collection of TabItems based on ObservableCollection called WorkspaceTabItemCollection, and gave it AddItem and RemoveItem methods which took a workspace and turned it into a TabItem and then added or removed it from the collection. Then this collection was bound to the workspaces tab control’s ItemsSource. As it was a collection of TabItems, it is displayed correctly by the TabControl.

As a quick and dirty way of getting WorkspaceTabItemCollection working, I was creating the TabItem contents by instantiating a new AllCustomersView or CustomerView as a UserControl, and passing in the workspace as the DataContext. However, this required the WorkspaceTabItemCollection to know about the various views, so I refactored it to get the appropriate data templates from the MainPageResources.xaml file and apply them instead. There’s a bit of a hack still in place to set the new TabItem as IsSelected=true, to make it become selected in the TabControl, as the Silverlight TabControl doesn’t support the IsSynchronizedWithCurrentItem property, rendering the first issue with SetActiveWorkspace mostly irrelevant. Oh well.

Workspaces are added to or removed from the WorkspaceTabItemCollection collection by hooking into the OnWorkspacesChanged event.

This worked well and things were starting to take shape. The next step was to get the selections in the AllCustomersView DataGrid to be totalled and display in the ‘Total selected sales’ area.

Tabs working

Issue Three: Can’t bind to DataGridRow IsSelected using a Setter Property in Silverlight

In the WPF version, Josh uses a Setter on the IsSelected property in the DataGridRow style to TwoWay bind to the DataGridRow’s underlying item’s IsSelected property. Then in the AllCustomersViewModel, this is detected in the OnCustomerViewModelPropertyChanged event, and the TotalSelectedSales property is in turn updated. This returns the sum of all TotalSales of each customer who’s IsSelected flag is set as true, and is the property that the ‘Total selected sales‘ area is bound to in the view.

Unfortunately, we can’t bind to the IsSelected property of a DataGridRow in Silverlight as it’s not publicly accessible. So we need another way to figure out what gets selected in the DataGrid and when.

After a bit of digging I found a great post by Alexey Zakharov which suggests using the CommandBehaviourBase class from Prism, and then add an attached property for the SelectionChanged event on the DataGrid.

We can then bind to a SelectedItemsChangedCommand in our ViewModel, which calls a SetCustomersAsSelected method and passes it a reference to the DataGrid (via the CommandParameter). Once we have the reference to the DataGrid, we can access the SelectedItems property of the DataGrid, and update the IsSelected property on our customers which will update TotalSelectedSales as detailed above.

This worked nicely, although I’m not entirely happy about the ViewModel needing to about a type of UI control (DataGrid). At least it avoids being tied directly to the View though.

With the AllCustomersView working nicely, we move on to the CustomerView form.

Selection working

Issue Four: Silverlight data validation needs to match the WPF sample

The CustomerViewModel translated across to Silverlight with only one slight issue: Josh uses CommandManager.InvalidateRequerySuggested to dirty the commands registered with the CommandManager when an error is raised, which is used in turn to enable/disable the Save button on the form (as it is bound to a Command, so is only enabled if the Command returns CanExecute as true)

CommandManager isn’t implemented in Silverlight 4 at present, so we use RaiseCanExecuteChanged directly on our SaveCommand instead. To enable this, I added two extra methods to Josh’s RelayCommand class: OnCanExecuteChanged and RaiseCanExecutedChanged, using code from an example at: http://www.silverlightshow.net/items/Silverlight-4-How-to-Command-Control.aspx

This enabled or disabled the Save button in the View as appropriate, however I wanted the validation error messages to match the WPF sample. To do this, I restyled the TextBox and ComboBox controls in the View to remove the validation tooltip, by clearing out the ValidationToolTipTemplate control template.

Then I got the validation messages displaying in TextBlocks under each control by changing the binding Josh was using from: {Binding Path=(Validation.Errors).CurrentItem} to: {Binding (Validation.Errors)[0].ErrorContent} instead.

The last part was to get the validation on the TextBoxes to fire per keypress, rather than just when they lose focus. In WPF, you use: UpdateSourceTrigger=PropertyChanged to achieve this, however that doesn’t exist in Silverlight 4. There are a few posts on different ways of how to simulate this in Silverlight, but I liked the approach of Thomas Claudius Huber: http://www.thomasclaudiushuber.com/blog/2009/07/17/here-it-is-the-updatesourcetrigger-for-propertychanged-in-silverlight/ best.

After attaching helpers:BindingUpdateHelper.UpdateSourceOnChange="True" to each TextBox, they validated on each keypress, and all was good.

Validation

Issue Five: Unit Tests!

Josh kindly included quite comprehensive unit tests in his sample project, so I wanted to get them working in the Silverlight version as well.

I started off with a standard C# Unit Test project, and copied the tests across and updated any namespaces. I also needed to tweak the tests which verify the CurrentItem property of the CollectionViewSource.

Attempting to run the tests resulted in a FileNotFoundException: "System.IO.FileNotFoundException: Could not load file or assembly ‘System.Xml.Linq, Version=2.0.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35′ or one of its dependencies. The system cannot find the file specified". At this point I was using Linq to XML (although refactored it out later on, so the project no longer needs it), and wanted to figure out what the problem was.

Turns out that the Unit Test project was using the version 4.0 System.Xml.Linq.dll, and so there was a mismatch between the versions. The quick solution was to hack the .csproj file (Right click on the project in Visual Studio -> Unload Project -> Right click again and choose Edit -> make your changes and save -> then Right click and choose Reload) to give a HintPath to the reference to point it to the Silverlight version like so:

$(ProgramFiles)\Microsoft SDKs\Silverlight\v4.0\Libraries\Client\System.Xml.Linq.dll

After fixing that, most of the tests passed, apart from any that were using the CustomerRepository. This turned out to be an issue with the GetResourceStream method, which uses Application.GetResourceStream to load in the customers.xml data file. When running via the Unit Tests, this was throwing a DllNotFoundException: "Unable to load DLL ‘agcore’: The specified module could not be found", as the Silverlight process wasn’t running, so the Application class couldn’t be accessed.

The quick solution to get the tests passing was to catch the DllNotFoundException and load the resource file using a standard StreamReader instead. A better long term solution would be to use something like Dependency Injection or Mocks instead.

The tests all passed fine after this, so I created a Silverlight Unit Test project as well to test them in there. They passed fine in this as well. You can run the tests by right clicking the SilverlightUnitTestsTestPage.aspx page in the MVVMSilverlightDemoApp.Web project and choosing View In Browser. This will launch a browser window with a Silverlight test harness which will run all the unit tests and show the results.

Unit Tests

So, that’s it. You can download the solution below and have a play around and compare it to Josh’s WPF original. Hope it helps.

MVVMSilverlightDemoApp.zip

Sample page using the AutoScalingTextBlock

Ed — Tue, 09 Mar 2010 16:11:00 +0000

Here’s a sample page using the AutoScalingTextBlock referred to in the previous post (An Auto Scaling TextBlock for Silverlight).

Use the GridSplitter controls (grey lines) at the right and bottom of the grid to change the size of the TextBlocks and see the font size change up and down, depending on the ‘ScalingMode’ setting of each AutoScalingTextBlock, or resize the page to also see it in action.

An Auto Scaling TextBlock for Silverlight

Ed — Tue, 09 Mar 2010 15:50:31 +0000

During a recent Silverlight project which required extensive localisations into eight different European languages, I discovered just how much text length can vary between cultures. This caused a couple of issues where there was a limited area for a specific piece of text to fit within, which would look fine in English, but then would not fit in a different language and would be cut off.

I thought this would be a good idea for a custom control, and so have written an AutoScalingTextBlock control.

It’s a simple text control (based on ‘ContentControl’) that shrinks or expands the font of the text to display all of the text in the preferred size of the TextBlock. See it in action: http://edventuro.us/2010/03/sample-page-using-the-autoscalingtextblock/

While deciding how to get started, I came across an excellent TextTrimming TextBlock on Robby Ingebretsen’s site: http://blog.nerdplusart.com/archives/texttrimming-textblock-for-silverlight which I used as a basis, and so am releasing my control under the same MIT license that he used. I hope it comes in handy for someone.

AutoScalingTextBlock:

Dependency Properties:

MinFontSize: This is the smallest size the font will be reduced to. Defaults to 8pt.
MaxFontSize: This is the largest size the font will be increased to. Defaults to 20.
ScalingMode: This controls if the font size should be scaled only up, or down, or both ways to fit the text within the boundaries of the textbox. Defaults to BothWays.
StepSize: This is the point size the font will be increased or decreased by each iteration until the text fits the desired size. Higher amounts will require fewer iterations, so will be faster, but the changes will be more abrupt. Defaults to 0.5.

Download the control: AutoScalingTextBlock.cs or a sample solution with examples in the Page.xaml file: AutoScalingControls.zip. Free to use under the MIT licence.