Archive | December, 2008

Dependency Injection as a tool for Reactive Programming

6 Dec

A few posts ago I talked about Reactive Programming and how I have decided to make it my primary concern architectually when developing. I recently read on the ninject site that an advantage of using a dependency injection framework such as ninject is that depenencies can be inspected, modified and be conditional. This is interesting, as this sounds like it offeres advantages comparable to data-binding. Being able to evaluate functions and relationships between code modules or elements is definately positive in my book because it allows us to have more ability to reason over information we have already provided.

A real world example, that I have seen demonstrated, could be as follows:

if an application is being executed then provide an implementation of a service that calls to say flicker, or amazon etc.

at design time we still want our visual studio or expression blend to work, and it would be nice if it had some data to display. We can do this by injecting a different depenedency link. This link would point to a dummy service that would just display data to help us in the designer views.

For more depth see:

While this could be done without dependency injection, code would start getting consolidated and repeated leading to code smells (ie bad practices). It is also worth stating that the example of using a webservice and specifying different implementations is quite a simple example. With that said I think the true power of Dependency Injection not only leads to better plug-ability of code modules but also the reasoning over these bindings.

The Singleton Pattern

6 Dec

One of my favorite gang of four patterns is the singleton pattern. The singleton pattern is a “Gang of Four” design pattern which is commonly used for maintaining one common instance of an object that is widely accessible. For C# implementations of the singleton pattern I previously used the 4th pattern on the following site: Recently however I have come to find issue with the singleton patterns in C# on two fronts. The first front being WPF view models. The second being from a Test Driven Development (TDD) perspective.

  1. The first point I have about the singleton pattern is that if you require the ability to subclass an existing class it becomes an anti-pattern. An example with WPF could be the requirement to adopt depenedency properties on a class. You could then argue that a class could be used to provide a single instance of the object. This would work for C# code, but it is problematic for XAML.  It is possible to maintain a single instance of a class in XAML with the ObjectDataProvider tag but then you would need to find that instance from the pages resources (usually a resource dictionary).  As I mentioned in a earlier post, it is important to me architecturally that XAML controls/resources are not directly referenced unless absolutely necessary.
  2. The second point is possibly more globally recognized, that singleton pattern is an anti-pattern when trying to unit test a class. For more on this you can google with the keywords of “singleton unit test” or check out the following blog post:

The singleton is still a great concept and a great tool to have in a developers arsenal but now I take a different approach by using an IoC (Inversion of Control/Dependency Injection) container called ninject which provides a Singleton attribute which provides uses the IoC facilities to maintain a reference to a single instance of an object. I feel that this approach will play well with WPF databinding because I believe the attribute will allow calls to be directed at the class without having knowledge of the factory maintaining the instance (Note: yet to confirm this in practice). I believe that other developers have opted for adopting service locators instead of singleton patterns. A blog post about the argument of IoC vs Service Locators is provided here:

Reactive Programming

5 Dec

The thing that made me jump into WPF and adopt a new fundamentalist regime of XAML pure-ism was a talk by
Ivan Towlson in late August on Reactive Programming. His slides are available here:

An example of Reactive Programming as Ivan explained that we use often is the SUM calculations in Excel. When we change the inputs into that sum calculation the calculation is retained and re-executed. The counter example (ie not using a reactive style) would be where you supply the sum equation and when displaying the sum value, your equation is not retained and only the resulting value is displayed. This means updating inputs of the sum don’t affect the sum value. I suggest checking out wikipedia for a better introduction:

To become a Reactive Programmer. I have the following suggestions/tools

  • Put as much display logic into XAML as possible as it is declarative (there is a bigger learning curve doing it this way as XAML is frustrating to learn)
  • Use as much databinding as possible. To do this you should adopt a view model. This allows you to update view data in the view model which will update the view. If you do this properly you should be able to never reference a XAML item by name from non XAML code(ie C# in my case).
  • Be mindful that LINQ is a staic one way action that can be databound but would require events to refresh and would only be a one way binding. I recommed Bindable LINQ to get around this problem.
  • In reactive programming, when displaying view data from the view-model I am of the opinion that Databinding is good. Events are bad. I think this point is fairly obvious. The most immediate benefit is that it simplifies code by reducing the number of lines required. The second benefit that comes to mind is the ability to potentially copy/serialize/insepect a binding for use elsewhere or for storage for later use.

As software devs we should be trying out best to reuse all of our code and reactive programming provides a great mindset for doing this. Unfortunately some of the xaml tags that I use for reactive programming are lacking in Silverlight, so I am doing my projects in WPF and am hoping in the future that Silverlight supports more WPF. A great example of a reactive WPF application that wouldn’t work in silverlight is the quake example which I provided in my first blog post.