In episode six of the ALT.NET podcast, Brad Wilson mentioned that we’ve only just touched the tip of the iceberg when it comes to dependency injection. He lamented that the existing frameworks have a configuration-based mindset, where you’re forced to wire your application’s components up in a very declarative fashion. He said he would prefer to see a DI framework that would allow you to favor convention over configuration.

This is a great idea, and it started the gears turning in my mind. Going with a more conventions-based mindset will let you wire your application up without the use of attributes, which helps to keep infrastructure concerns from cluttering your codebase. After an interesting question was posted to the Ninject user group, it occurred to me that Ninject supports a “conventions over configuration” mindset already.

For example, let’s say you have two sources for configuration in your application, a LocalConfigurationSource that loads configuration information from a local file, and a RemoteConfigurationSource that loads configuration from a remote database. Services that depend on configuration information will need one or the other of these services to set up configuration. Let’s say you have a consuming service that loads some of its configuration from the local source, and some from the remote source:

public class Service {
  public Service(IConfigurationSource remoteConfig, IConfigurationSource localSource) {
    //...
  }
}

In order to get Ninject to resolve these dependencies and call this constructor, you will need to declare bindings that differentiate between the two implementations of IConfigurationService. If you favor a declarative approach, you could create [Remote] and Local attributes, and use them to decorate the individual constructor arguments:

public class Service {
  public Service([Remote] IConfigurationSource remoteConfig, [Local] IConfigurationSource localSource) {
    //...
  }
}

Then your bindings would look like this:

Bind<IConfigurationSource>().To<RemoteConfigurationSource>()
  .WhereTargetHas<RemoteAttribute>();
Bind<IConfigurationSource>().To<LocalConfigurationSource>()
  .WhereTargetHas<LocalAttribute>();

However, if you’d rather not have to put the attributes in your constructor, you can rely on a conventions-based approach instead. For example, you can create a rule that says that if you want an instance of RemoteConfigurationSource, your argument has to begin with “remote”, and if you want an instance of LocalConfigurationSource, it has to begin with “local”. To do this, you would create bindings like this:

Bind<IConfigurationSource>().To<RemoteConfigurationSource>()
  .Only(When.Context.Target.Name.BeginsWith("remote"));
Bind<IConfigurationSource>().To<LocalConfigurationSource>()
  .Only(When.Context.Target.Name.BeginsWith("local"));

By using these bindings, your consuming service could have a constructor with no attributes, as shown in the first code example.

I’ve added an additional page to the Ninject dojo describing these ideas, and I’d like to hear some feedback. If you have ideas on how to improve upon this, I’d be very interested to hear them!

When I introduce dependency injection to developers, I often receive the complaint that it’s not significantly better than the service locator pattern. The main disadvantage of a service locator is that you’re required to couple all of the services in your application to the service locator in order for them to resolve their dependencies. By using a DI framework instead, you can keep your services very loosely-coupled.

However, there are some advantages of the service locator pattern. In particular, it’s much easier to implement hybrid activation — when some of the values in a constructor are provided by the consuming code, and some are provided by the framework. Hybrid activation is common in situations where you don’t need (or want) your DI framework to control the instantiation behavior of the type, but you still want to be able to resolve dependencies that are required for the instance.

In Ninject, hybrid activation is possible through the use of context parameters, which allow you to provide values for specific constructor arguments when you request the instance. However, context parameters can only be used for active requests — that is, calls to the kernel’s Get() method. If you often call Get() on the kernel, you’re using it as a service locator anyway.

The reality is, there’s nothing inherently wrong with using a service locator — when used in the right way, it can greatly simplify your code. I don’t think that service locator and dependency injection are mutually exclusive; in fact, I’ve found that it can actually be very effective when used in conjunction with a dependency injection framework like Ninject.

For example, let’s say you have an EventWatcher service that listens for a named event on an IMessageBroker, reads event information from the message, and triggers a specified callback. The implementation of such a service might look like this:

public class EventWatcher<T> {
  public EventWatcher(string eventName, Action<T> callback, IMessageBroker messageBroker) {
    //...
  }
}

You can’t easily activate a service like this using the Ninject kernel (at least without using context parameters), since the first two constructor arguments have to be supplied from the consuming code, and only the third is actually a dependency that should be activated via the kernel.

However, let’s introduce a simple service locator, which just delegates activation requests to a Ninject kernel:

public static class ServiceLocator {
  private static IKernel _kernel;
  public static void Initialize(IKernel kernel) {
    _kernel = kernel;
  }
  public static T Get<T>() {
    return _kernel.Get<T>();
  }
  public static object Get(Type type) {
    return _kernel.Get(type);
  }
}

Then, when we initially create our kernel, we just have to pass it to the Initialize() method of the ServiceLocator:

public static class Program {
  public static void Main() {
    using (var kernel = new StandardKernel(...)) {
      ServiceLocator.Initialize(kernel);
      //...
    }
  }
}

Using the service locator, we can alter our implementation of EventWatcher to make it easy to pass in the event name and callback method arguments, while still leaving it flexible enough to swap out the implementation of IMessageBroker. This is particularly useful for testability, since you can easily swap in a mock implementation of IMessageBroker in your tests.

public class EventWatcher<T> {
  public EventWatcher(string eventName, Action<T> callback)
    : this(eventName, callback, ServiceLocator.Get<IMessageBroker>())
  { }
  [Inject]
  public EventWatcher(string eventName, Action<T> callback, IMessageBroker messageBroker) {
    //...
  }
}

As you can see, if the more limited constructor is called, the EventWatcher asks the ServiceLocator to resolve the instance that should be used. Notice also that I’ve still kept the [Inject] attribute on the second constructor, in case you want to activate the type using the kernel and context variables.

While this is a useful technique in limited use, it’s important to be careful how much you rely on it. Remember that every time you use a service locator instead of dependency injection, you’re coupling your type to the service locator — and since it’s a static method call, it’s coupled just about as tightly as you can get. Again, though, taken in small doses, this technique can actually simplify your code and make it much more flexible.

One of my favorite new features of C# 3.0 are extension methods. However, for some projects I’m not willing or able to target version 3.5 of the .NET framework. Up until today I thought that this meant I was out of luck in terms of being able to use extension methods, until Scott Hanselman’s post about them got the gears turning in my head.

If you try to add an extension method in a project that targets version 2.0 of the .NET framework, you’ll get an error saying you have to reference System.Core. However, the error is misleading. Extension methods are just normal static methods tagged with the [Extension] attribute. This attribute is actually just added by the compiler behind the scenes. In .NET 3.5, it lives in System.Core, but if you define your own attribute like this:

namespace System.Runtime.CompilerServices
{
  [AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = false)]
  public class ExtensionAttribute : Attribute
  {
  }
}

Your extension methods will suddenly spring to life! After testing, I realized I’m not the first one to figure this out, but it’s definitely something I’ll keep in my bag of tricks.

When your application communicates with the user, it should do so in a way that is helpful. One of the most important times that software communicates with the user is when an error occurs. This can be a very delicate situation, because the user is unlikely to be pleased that their request was denied. There is an art to error messages that is sadly lacking in most software.

Error messages should never:

1. Give too little information.
2. Give too much information, unnecessarily confusing the user.
3. Provide no solution to the problem.
4. Make the user so angry that he/she smashes the monitor.

For example, take this, one of my favorite error message from Windows XP:

I see this message about 50% of the time when I try to “safely remove” my portable WD Passport hard drive. Every time I see this message, it makes me want to drive to Redmond and start dealing out ass-whippings give everyone a stern talking-to. Simply put, this message exemplifies everything that’s wrong with error messages. If it would tell me what application was locking the file on the disk, I would shut it down. I would even be happy to kill it with the task manager. Sadly, I get no hints. I’m sure this error message was easy to write, but it’s no more useful than the “lazy programmers” haiku error message by Charlie Gibbs:

Errors have occurred.
We won’t tell you where or why.
Lazy programmers.

Error messages are important for normal applications, but nowhere are they more important than in software libraries. With Ninject, I’ve gone through great pains to make the exception messages as useful as possible. Here’s an example error message, in this case if you try to activate a service that has a circular reference with another service. (Note that the web layout might cause odd word wrapping. Trust me that it’s formatted a little more cleanly. :)

Ninject.Core.ActivationException: Error activating CircularMockA:
Circular dependencies detected between constructors. Consider using property injection and implementing IInitializable instead.
Using default self-binding of CircularMockA (via StandardProvider)
  declared by SampleModule.Load() at SampleModule.cs:85
Activation path:
  3) passive injection of service CircularMockA into parameter mockA on constructor of type CircularMockB
     using default self-binding of CircularMockA (via StandardProvider)
     declared by SampleModule.Load() at SampleModule.cs:85
  2) passive injection of service CircularMockB into parameter mockB on constructor of type CircularMockB
     using default self-binding of CircularMockB (via StandardProvider)
     declared by SampleModule.Load() at SampleModule.cs:86
  1) active request for CircularMockA
     from Program.Main() at Program.cs:91
     using default self-binding of CircularMockA (via StandardProvider)
     declared by SampleModule.Load() at SampleModule.cs:85

This is a good error message. It clearly describes what happened, and gives a possible solution. It directs the user back to the exact line number where the error occurred (which is sometimes lost when exceptions get wrapped). It then goes so far as to show every step in the activation process, starting with the first time the user asked Ninject for something — the active request, shown last. That way, if the user doesn’t quite understand how activation works in Ninject, they should still be able to understand what the framework is doing. This is in addition to the stack trace that is available with all exceptions in .NET.

If I wanted to pattern my exception message around the one from the Safely Remove Hardware applet, it would look more like this:

System.Exception: Couldn't complete request. Try again later.

There are some libraries out there that have fantastic error messages. The Castle Project (particularly MonoRail) and Guice come to mind. However, some libraries that are otherwise great (NHibernate, I’m looking at you) have some terrible error messages.

I’m guilty of this too. One of the first applications I wrote when I started programming professionally was a PDF generator, written in C++. It was designed as an executable, and controlled by command-line parameters. This utility was embedded in other systems, primarily in a Linux environment, so we decided to use shell-return codes to indicate if there was a problem with the generation of the PDF. Sadly, we ran out of time before we implemented the error code system. To this day, the application returns one of three codes:

• -1: There was a problem with configuration.
• 0: The PDF was successfully generated.
• 1: There was some sort of error generating the PDF.

Once the utility was configured, its configuration wouldn’t generally change, so 99% of errors just return 1. We were creative enough, though, to include a log file, which could be configured to dump the entire contents of the PDF document in a debug-type display. It was even output in HTML, with some JavaScript to expand and collapse the giant tree in which it was displayed. Unfortunately, there wasn’t any real level-filtering of the log… it was either on or off. So, if you tried to generate a 200 page PDF, your log file would be somewhere around 300MB of HTML. Try loading that in Internet Explorer and clicking the “expand all” button… :)

My point of all this rambling is this: errors happen, and reporting them correctly is a vital part of any piece of software. If you’re going to spend the time to write a killer application, or a killer library, make sure you spend time to deliver proper error messages to your users. As a good exercise, show your error message to a user who understands how your application works and ask: can you explain what the problem is by reading this? If the answer is no, it’s time to go back to the drawing board. It’s tempting to just say “shit’s broke, try again later”, but you’ll pay for it eventually.

In the shower this morning, as the haze of sleep was clearing, I was thinking about delegates in C#. (Yes, I’m a complete and total geek. As if there was any debate on that issue. :) An interesting thought occurred to me, though, so I naturally had to throw together a proof of concept. It’s another one of those ideas whose usefulness is debatable for most cases, but is interesting nonetheless.

A functor, which is a term from functional programming, is an function represented as an object. In C#, functors are implemented as delegates. C# 2.0 introduced some language features like implicit delegate creation and invocation, which give the appearance of first-class functions. This significantly narrows the gap between actual method declarations and delegates.

A class is essentially a collection of methods along with some data that defines its state. Consider this class definition:

   1: public class Formatter

   2: {

   3:   public string Format(string message)

   4:   {

   5:     return message.ToLower();

   6:   }

   7: }

Very straightforward. To use this Formatter class, you could do something like this:

   1: public static class Program

   2: {

   3:   public static void Main()

   4:   {

   5:     Formatter fmt = new Formatter();

   6:  

   7:     // Outputs "my message!"

   8:     Console.WriteLine(fmt.Format("My Message!"));

   9:   }

  10: }

Nothing groundbreaking there either. But what if, instead of actually defining your method directly, you did this instead?

   1: public class Formatter

   2: {

   3:   public Functions.Format Format = delegate(string message)

   4:   {

   5:     return message.ToLower();

   6:   }

   7:  

   8:   public class Functions

   9:   {

  10:     public delegate string Format(string message);

  11:   }

  12: }

Take a close look at that snippet. Rather than declaring a Format method on the Formatter type, we’ve given it a public Format field. The Format field is of type Formatter.Functions.Format, which is a delegate defined in an inner class called Functions. (The inner type just keeps the outer Formatter type clean of any delegate definitions.) Then, using anonymous method syntax, we’ve assigned the Format field a value, which is the same as our previous implementation of the Format method.

What we’ve essentially done is separated the signature of the method from its implementation. You can still use the Formatter just like before:

   1: public static class Program

   2: {

   3:   public static void Main()

   4:   {

   5:     Formatter fmt = new Formatter();

   6:  

   7:     // This triggers the Format delegate, resulting in the same

   8:     // output of "my message!"

   9:     Console.WriteLine(fmt.Format("My Message!"));

  10:   }

  11: }

But, since the implementation is separate from the declaration, we can do fun stuff like:

   1: public class Program

   2: {

   3:   public static void Main()

   4:   {

   5:     Formatter fmt = new Formatter();

   6:  

   7:     // Change the implementation of Format.

   8:     fmt.Format = delegate(string s) { return s.ToUpper(); };

   9:  

  10:     // This outputs "MY MESSAGE!"

  11:     Console.WriteLine(fmt.Format("My Message!"));

  12:   }

  13: }

You could even get more creative:

   1: public class Program

   2: {

   3:   public static void Main()

   4:   {

   5:     Formatter fmt = new Formatter();

   6:  

   7:     // Save a copy of the original implementation (ToLower)

   8:     Formatter.Functions.Format func = fmt.Format;

   9:  

  10:     // Wrap the function with another implementation.

  11:     fmt.Format = delegate(string s) { return "The message is [" + func(s) + "]"; };

  12:  

  13:     // This will output "The message is [my message!]"

  14:     Console.WriteLine(fmt.Format("My Message!"));

  15:   }

  16: }

This technique is used pretty commonly in dynamic languages like Ruby, but it can still be applied to more static languages like C#. Arguably, it would be nice if there was support for this in the language (say through the virtual keyword, or a new one like externalizable), but I have a feeling it would be misused pretty quickly. :)

In my last post a few days ago, I described a simple trick for creating thread-safe wrappers for event handlers in WinForms controls. I’ve discovered an even simpler approach that is much more general-purpose:

   1: public static class ThreadSafe

   2: {

   3:   public static void Invoke(ISynchronizeInvoke context, MethodInvoker method)

   4:   {

   5:     if (context.InvokeRequired)

   6:       context.Invoke(method);

   7:     else

   8:       method();

   9:   }

  10: }

Then, in your control, you can define methods like this:

   1: public class MyForm : Form

   2: {

   3:   public void SetMessage(string message)

   4:   {

   5:     ThreadSafe.Invoke(this, delegate

   6:     {

   7:       this.lblMessage.Text = message;

   8:     });

   9:   }

  10: }

Through the magic of variable capturing with anonymous methods, you don’t need to pass the arguments into your inner method (the delegate that you’re passing to the Invoke method). This also means that the Invoke method can be used to protect methods with any signature. Be aware, though, that the captured variables are read-only in the inner context. (More information about captured variables and the difference between lexical closures in C# and Ruby is available here.)

I haven’t given this too much testing so far, but it seems to work!

I really need a full post soon, because a whole bunch of stuff is happening with Ninject (neé Titan). Unfortunately (for my blog at least), we just started our first sprint for a new project that I’m leading at my day job, so at least until it stabilizes my time is going to be pretty well filled. I came up with something that seems pretty useful, though, so I wanted to share it.

There’s a rule in Windows development often jokingly referred to as The One Rule. Basically, it says that you cannot modify any part of the user interface from any threads other than the user interface thread. This is due to the way Windows handles messaging, which gets into message pumps and all sorts of other fun low-level stuff that I don’t understand enough to get into here. :) In order to create responsive user interfaces, though, we have to do most of the work in background threads. This means that eventually, the background threads will need to tell the interface to update itself to inform the user of any changes.

.NET has provided a resolution to this apparent contradiction via Control.Invoke(). The pattern typically goes like this:

   1: public class SampleForm : Form

   2: {

   3:   public SampleForm()

   4:   {

   5:     Worker worker = new Worker();

   6:     worker.ImportantEvent += HandleImportantEvent;

   7:   }

   8:  

   9:   private void HandleImportantEvent(object sender, ImportantEventArgs e)

  10:   {

  11:     if (this.InvokeRequired)

  12:     {

  13:       this.Invoke(HandleImportantEvent, sender, e);

  14:       return;

  15:     }

  16:  

  17:     // Update the user interface to show an important event happened.

  18:   }

  19: }

The block at the beginning of the event handler protects the interface from being erroneously updated by checking the control’s InvokeRequired property. If it’s true, instead of actually executing the method directly, it calls Invoke(), which essentially queues the method call in the Windows message queue for later execution.

This works great, but it’s a real pain to have that block in every method that could feasibly be called from another thread. It’s easy to forget, too, with dire consequences: at least until .NET 2.0, this caused your application to lock up with no error messages at all. (Version 2.0 solves this by throwing an exception if you violate the One Rule.) Using the magic of anonymous methods, you could do this instead:

   1: public class SampleForm : Form

   2: {

   3:   public SampleForm()

   4:   {

   5:     Worker worker = new Worker();

   6:     worker.ImportantEvent += ThreadSafe.EventHandler<ImportantEventArgs>(this, HandleImportantEvent);

   7:   }

   8:  

   9:   private void HandleImportantEvent(object sender, ImportantEventArgs e)

  10:   {

  11:     // Update the user interface to show an important event happened.

  12:   }

  13: }

The magic happens in the ThreadSafe static class:

   1: public static class ThreadSafe

   2: {

   3:   public static EventHandler<T> EventHandler<T>(Control context, EventHandler<T> handler)

   4:     where T : EventArgs

   5:   {

   6:     return delegate(object sender, T args)

   7:     {

   8:       if (context.InvokeRequired)

   9:         context.Invoke(handler, sender, args);

  10:       else 

  11:         handler(sender, args);

  12:     };

  13:   }

  14: }

This will wrap your real event handler with an anonymous method that takes care of the Control.Invoke() if necessary. Note that you can only use this type with event handlers of the form EventHandler<T>, but you should be using that anyway… :)

I discovered an interesting .NET 2.0 trick recently while tinkering with one of the projects I’m working on. In practice, its usefulness is debatable, but it’s pretty cool anyways. I’ve taken to calling the trick self-referential generics. Another way to think of it is a way to “invert” type safety in a type hierarchy.

Consider a simple type hierarchy, with an abstract base type, AbstractFoo, and a concrete subtype, ConcreteFoo:

public abstract class AbstractFoo
{ ... }

public class ConcreteFoo : AbstractFoo
{ ... }

Now, let’s say that our design requires that we place our AbstractFoos in collections, and that each AbstractFoo instance needs a reference to the collection it resides in. We can accomplish this by exposing a property:

public abstract class AbstractFoo
{
  private ICollection<AbstractFoo> _collection;

  public ICollection<AbstractFoo> Collection
  {
    get { return _collection; }
    set { _collection = value; }
  }
}

Then, in our program, let’s say we want to create a collection of ConcreteFoos:

public static class Program
{
  public static void Main()
  {
    ConcreteFoo foo = new ConcreteFoo();
    Collection<ConcreteFoo> collection = new Collection<ConcreteFoo>();
    collection.Add(foo);

    foo.Collection = collection; // Error!
  }
}

Notice that we have a problem. Even though we’re creating an instance of ConcreteFoo, the property that’s exposed on it is still typed as ICollection<AbstractFoo>. If we were to then create a Collection<ConcreteFoo>, we could add the ConcreteFoo instance to it, but we couldn’t set the value of our Collection property.

The problem here is that generic type arguments are not polymorphic — that is, even though a ConcreteFoo is an AbstractFoo, and you can put ConcreteFoos into a Collection<ConcreteFoo>, a Collection<ConcreteFoo> is not a Collection<AbstractFoo>. Note that our design could feasibly require the collection to store any subtype of AbstractFoo, but in our case we’re assuming that the collection will store values that are all of the same subtype.

So what can we do? It turns out that the CLR provides us a strange feature that solves our problem. Consider the following replacement for our simple hierarchy:

public abstract class AbstractFoo<T>
  where T : AbstractFoo<T>
{ ... }

public class ConcreteFoo : AbstractFoo<ConcreteFoo>
{ ... }

Take a minute and let that type definition make sense. (It took me awhile.) Notice that because of the type constraint, the generic parameter T refers to the type AbstractFoo<T> itself, hence, it is self-referential. At first glance, it may appear that the runtime won’t be able to assure type-safety, but since all of the generic arguments are defined, it can successfully instantiate the type. Also, as you may know, the where constraint on the AbstractFoo<T> type only requires that the type T be either AbstractFoo<T> or one of its subtypes (also referred to as the Liskov Substitution Principle, or the “is-a test”).

So why in the world would we want to do such a thing? By defining the type in this manner, inside of the AbstractFoo<T> type definition, the type T refers to the current concrete subtype of AbstractFoo. Effectively, we have “inverted” the type safety, pushing up the knowledge of the concrete type from the implementation into the base types.

Knowing this, we can change our property definition in AbstractFoo<T>:

public abstract class AbstractFoo<T>
  where T : AbstractFoo<T>
{
  private ICollection<T> _collection;

  public ICollection<T> Collection
  {
    get { return _collection; }
    set { _collection = value; }
  }
}

Now, since T refers to the actual concrete type that we’re dealing with, we can do this in our application:

public static class Program
{
  public static void Main()
  {
    ConcreteFoo foo = new ConcreteFoo();
    Collection<ConcreteFoo> collection = new Collection<ConcreteFoo>();
    collection.Add(foo);
    foo.Collection = collection;
  }
}

Since the ICollection<T> exposed on AbstractFoo<T> is now typed as ICollection<ConcreteFoo> in the case of a ConcreteFoo, we can now create our Collection<ConcreteFoo> and set it directly.

Like I said, it’s not something you’ll use every day, but interesting nevertheless.