How not to use dependency injection frameworks

Just like any tool, a DI framework can be misused. Here’s a quick guide to understand why you might want such a tool and how to avoid shooting yourself in the foot with it.

The goal

Inversion of Control (IoC) is a very general concept which I’d describe as ‘shifting responsibility’. The goal is to make the code reusable without having to think of every possible use up front. Essentially, the Open Closed Principle.

For example, using a test framework like NUnit means that the framework (rather than your code) has control over when your code is called. By keeping the mechanism of running the test separate from the test itself, your code will be reusable with a different test framework.

Another example (more relevant to the main topic) is making a class’s dependency configurable, so rather than a class Logger calling File.WriteAllText, it might call WriteText on a member of type IPersistentStore. If the behavior of the IPersistentStore is controlled by something outside the class, then we’ve inverted control of what the Logger will achieve, or shifted the responsibility of where the logger persists the given data. Here are two examples of Dependency Injection in action:

public interface IPersistentStore
{
    void WriteText(string text);
}

public class Logger
{
    public IPersistentStore PersistentStore { private get; set; }

    public Logger(IPersistentStore persistentStore)
    {
        PersistentStore = persistentStore;
    }

    public void LogError(Exception exception)
    {
        PersistentStore.WriteText(exception.Message);
    }
}

Obviously, only one of the solutions (public setter, or constructor) need be used. The danger of the public setter is that the caller may forget to call it – therefore you may want to set a sensible default if you use this style. I’m personally of the mind that a constructor should take everything required for the object to work correctly.

Another method which I should mention is the Service Locator Pattern (SLP). Long story short, you introduce another layer of indirection by injecting an object that knows how to locate/create a concrete instance of an IPersistentStore. It’s considered an anti-pattern by many so beware of hiding dependencies and turning what would otherwise be compile-time errors into runtime failures using it. The factory pattern will probably serve you better.

Side effects of using constructor injection and the factory pattern may include:

  • Writing code against contracts of interfaces rather than implementations that are subject to change. i.e. Loose coupling.
  • Fewer ‘just in case’ configuration parameters added for possible future functionality.
  • More testable code – as different varieties of test doubles can be used.
  • Confusion when this concept is over-applied, as you trawl through 20 classes and interfaces just to print Hello World.

Using frameworks

Dependency Injection frameworks are tools that can cut down on some of the boilerplate code that you might end up writing to achieve the above goal.

Some pretty well-respected people dislike DI frameworks. That should be a good hint that there are at least some pitfalls to avoid. Since this is an area where people disagree the most important piece of advice I can give is to leave yourself open to changing your mind later. You should always consider the cost of switching when starting to use a new technology.

One of the main objections I’ve heard is from people who have locked themselves into their DI framework by scattering references to it all over their code. This is not necessary to get them to work but is easily done, and is a slippery slope once you’ve started.

If you are doing DI, and you’re hitting problems like:

  • Too many very similar looking factories.
  • Implementing singleton patterns all over the place.

Then a good DI framework may be able to help you.

Many frameworks have various “automagic” binding options which match things up based on name. Switch them off, do not be tempted. You will be scattering an important responsibility all over your codebase and putting constraints on choosing appropriate names for the context.

Initialization is a responsibility in its own right, so it should have its own classes. Ideally you should write down these “bindings” of concretions to abstractions as “high up” as possible. I’d also encourage you to put all the bindings in a separate initialization phase of your application which runs before any normal application actions occur. This way you can test that phase independently.

In summary:

  • Use constructor injection
  • Segregate interfaces
  • Write and test your application initialization as its own responsibility
  • If you use a DI framework:
    • Switch off the automagic features
    • Minimize your dependency on it (especially static classes)
Posted in Principles | Tagged , , , | Leave a comment

SOLID refresher

Single Responsibility

This principle says a module should have precisely one reason to change.

Encapsulate sources of high uncertainty first. If it’s highly likely to change, make sure it can change separately from other things.

Open Closed

My previous post goes into more detail on this principle. To summarise:

  • Don’t get carried away with this one and use it as an excuse to implement things “in case they’re needed in the future”.
  • Do take a few moments to consider what might change in future, and shape the thing you’re about to implement to prepare for it

Liskov Substitution

“Don’t lie with inheritance”.

I’d generalize to:

Reluctance to lie should be proportional to the difficulty of cleaning up that lie when its burden is too great.

Interface Segregation

From Wikipedia: “no client should be forced to depend on methods it does not use.[1]

The lower down in your dependency tree the interface is, the more important it is to segregate it.

Dependency Inversion

Depend on abstractions (interfaces) rather than concretions.

Don’t hide your dependencies, use constructor injection of the interfaces your object needs. The topic of Dependency Injection frameworks often comes under this heading, but probably deserves a separate post. If you do use one, make sure that only the very highest layer of your application knows about it.

Aside | Posted on by | Tagged | Leave a comment

Evil Regexes

Server side input validation is an essential part of basic web security. Most people use regexes to deal with this. But if you’re not careful, your input validation could be used to denial of service attack your server.

Problem

Take the contrived example regex (a+)+

The string aaaa could match as (aaaa), (aaa)(a), (aa)(aa), (a)(aaa), (a)(aa)(a), (a)(a)(aa), (aa)(a)(a). The simplest algorithm has a state machine for each of these possibilities it checks in parallel. Of course you could easily avoid this by stopping at the first match…but what about a string that doesn’t quite match, like “aaaaaaaaaaaaaaaaaab”?

It turns out there are better algorithms for standard regexes which aren’t as vulnerable to this exploit, but they only work for pure regexes. Since many regex systems support extensions (e.g. backreferences) which are beyond such algorithms, they don’t bother supporting the improved algorithm even when the extensions aren’t used.

Solutions

  • Do length validation first to slightly increase the resources required for an attack.
  • Use pure regexes and an efficient matcher to avoid the problem completely.
  • Look out during code review for any repetition containing:
    • something which itself repeats, or
    • overlapping alternation e.g. (a|aa)

Note: You can’t even assume that libraries you depend on are doing it right. ASP MVC on Dot Net 4.5 shipped with three evil regexes in its default input validation attributes.

Summary

Evil regexes cause a number of possible paths exponential in the input length. An attacker can very easily overload your server using them. If you care about protecting your servers, understand evil regexes and code review to weed them out.

See owasp for further information.

Posted in C# | Tagged | Leave a comment