Home » Dependency Injection » Dependency Injection Frameworks Are NOT Dependency Injection

Dependency Injection Frameworks Are NOT Dependency Injection

land-0148

As you start your journey down the road of Unit Testing you will discover that part of what makes code testable is this concept of Dependency Injection.  As you explore further, you will see people mentioning various Dependency Injection frameworks. You may naturally assume that to implement Dependency Injection, you will need to select an use a Dependency Injection framework.

But, Dependency Injection has nothing to do with using a Dependency Injection framework.  The frameworks are there because:

1.  much of our existing code is code that has too many dependencies and the framework helps us break those dependencies without having to refactor too much of our code and

2. to give us a way to easily swap out one object for another when our code is structured in such a way as to not have dependencies at all.

So, what then is Dependency Injection?

I once heard this maxim that explains it best,

Classes should either create stuff, or do stuff, but no one class should do both.

Much of our code looks something like this:

private static void ReceiveSAMLResponse(
    out SAMLResponse samlResponse, 
    out String relayState)
{
    // Receive the SAML response over the 
    //specified binding.
    XmlElement samlResponseXml;

    ServiceProvider.ReceiveSAMLResponseByHTTPPost(
        HttpContext.Current.Request, 
        out samlResponseXml, out relayState);
    SAMLResponse resp = new SAMLResponse(samlResponseXml);
    XmlElement samlAssertionElement = 
        resp.GetSignedAssertions()[0];

    // Verify the response's signature.
    XmlDocument doc = new XmlDocument();
    //metadata file path (holds the description key).
    doc.Load(HttpContext.Current.Server.MapPath("~/SAML.xml"));
    XmlElement root = doc.DocumentElement;

    if (!SAMLAssertionSignature.Verify(
        samlAssertionElement, ReadMetadata(root)))
    {
        samlResponse = null;
        relayState = null;
        return;
    }
    // Deserialize the XML.
    samlResponse = new SAMLResponse(samlResponseXml);
}

Yes, this is real code from a system I worked on.  The original code was written three or four years ago and this specific code is code I was given by another company.  I just used copy and paste inheritance to get it working in our code.

That’s not to say I haven’t written cod that has just as many problems.

There are several things that are wrong with this code, but for now all I want to focus on is the Dependency Injection issue.

All this code is trying to do is to deserialize the encrypted samlResponse object that was posted to the login form.  At least this code isn’t in the login form!  It has that much going for it.

But here are places where it is dependent on too much:

  • ServiceProvider is a static class and called directly.
  • ReceiveSAMLResponseByHTTPPost is dependent on the Request object that we retrieve from HttpContext.
  • I create a new SAMLResponse object right before I call GetSignedAssertions()
  • I create a new XmlDocument object so I can load the SAML.xml file
  • SAMLAssertionSignature is static and called directly

In fact, this method is one huge dependency mess.  And I’m very aware of the mess that it is in because the company we wrote this code for just recently switched providers.  As we tried to get this working, I had no way of testing this code in isolation without adding code directly into this method.  We got it working, but it didn’t have to be that hard.

So, here’s what I’d do to this code.

  • Since ServiceProvider and SAMLAssertionSignature are calls to a third party API, I would wrap them in a none static class that I can instantiate.
  • I would have the class that ultimately calls this method either pass in the dependent objects to the constructor, pass them in to the method that calls this, or set properties in the class.  This is what it means to inject dependencies.
  • I would look for some way to avoid creating a new SAMLResponse object.  I’m not looking at the API documentation, but it would be great if I could new up the object and call a method, or set a property to give it the samlResponseXml variable.  If I had to, I’d probably wrap SAMLResponse in another class so that I could gain this functionality.
  • Finally, I would make each of the dependent object based on an interface so that I could swap them out.  In the case of some of these classes, I may need to wrap them in another class that I have control over so that I can implement an interface.  For example, as things stand, I would not be able to create a fake request object because Request is a system class that does not implement an interface.

Advantages

After making all of these changes, I would be able to create a test harness for this code, create fake versions of the objects, and verify that this method does what we intend for it do do.

Where this would have been particularly helpful is over this last week when we were trying to get this all working with the new provider.  In that case, I could have faked out the request object with what they were sending us and run it through a debugger to figure out what wasn’t quite right.

No Dependency Injection Framework

Finally, you’ll notice that no where in this code did I have to use a Dependency Injection framework to get this all working.

Other Places Talking About Dependency Injection

 

Other post in Dependency Injection
Summary
Article Name
Dependency Injection Is Not Dependency Injection
Description
Dependency Injection has nothing to do with using a Dependency Injection framework. The frameworks are there because ... (click the link to find out more)
Author

Related Post

  • Excuses For Not TestingExcuses For Not Testing As I started my own journey into unit testing, I slowly began to realize that it was really easy to come up with reasons to NOT test my code as I was writing it, even once I understood […]
  • Why Johnny Can’t do Test Driven DevelopmentWhy Johnny Can’t do Test Driven Development Last week we looked at a few excuses developers give for not testing their code as they develop it (Excuses For Not Testing).  We finished that by mentioning that most of the code you […]
  • Test Driven SpecificationsTest Driven Specifications Several years ago, long before the community was actively talking about Test Driven Development, I worked for a short time at a company as a “bug fixer.”  That was my role.  They […]
  • What Not To TestWhat Not To Test Many people believe that implementing Test Driven Development means that you need to have a test for every line of code in your system.  When  they start thinking about TDD in […]
  • Software Architecture without Test Driven Development is DANGEROUS!Software Architecture without Test Driven Development is DANGEROUS! I’ve had two incidents recently that have shown me how TDD impacts Software Architecture.  Both of these are with code I’m working on. What Software Architecture Might Do Software […]

About Dave Bush

Dave Bush is a Full Stack ASP.NET developer focusing on ASP.NET, C#, Node.js, JavaScript, HTML, CSS, BootStrap, and Angular.JS.Does your team need additional help in any of the above? Contact Dave today.

One Pingback/Trackback