Rhino Mocks, Dependency Injection, and Separation of Concerns

Question

I am new to mocking and dependency injection and need some guidance.

My application is using a typical N-Tier architecture where the BLL references the DAL, and the UI references the BLL but not the DAL. Pretty straight forward.

Lets say, for example, I have the following classes:

class MyDataAccess : IMyDataAccess {}
class MyBusinessLogic {}

Each exists in a separate assembly.

I want to mock MyDataAccess in the tests for MyBusinessLogic. So I added a constructor to the MyBusinessLogic class to take an IMyDataAccess parameter for the dependency injection. But now when I try to create an instance of MyBusinessLogic on the UI layer it requires a reference to the DAL.

I thought I could define a default constructor on MyBusinessLogic to set a default IMyDataAccess implementation, but not only does this seem like a codesmell it didn't actually solve the problem. I'd still have a public constructor with IMyDataAccess in the signature. So the UI layer still requires a reference to the DAL in order to compile.

One possible solution I am toying with is to create an internal constructor for MyBusinessLogic with the IMyDataAccess parameter. Then I can use an Accessor from the test project to call the constructor. But there's still that smell.

What is the common solution here. I must just be doing something wrong. How could I improve the architecture?

Answer 1

You can define your classes like this:

public class MainForm : Form
{
    private readonly businessLogic;

    public MainForm(IBusinessLogic businessLogic)
    {
        this.businessLogic = businessLogic;
    }
}

public class BusinessLogic : IBusinessLogic
{
    private IDataLayer dataLayer;

    public BusinessLogic(IDataLayer dataLayer)
    {
        this.dataLayer = dataLayer;
    }
}

public class DataLayer : IDataLayer
{
    public DataLayer(string connectionString)
    {
    }
}

Note how the main form doesn't know about the DAL here. Now we do need a piece of code which knows all the classes, so that they can be wired together. This is typically done at the start of the application:

public static void Main(string[] args)
{
   var dataLayer = new DataLayer("foo");
   var businessLogic = new BusinessLogic(dataLayer);
   var mainForm = new MainForm(businessLogic);

   Application.Run(mainForm);
}

Of course, this is a simplified example. If you have dozens or hundreds of classes in practice, then such start-up wiring can get very big and complicated, especially when cyclic dependencies come into play. That's why dependency injection frameworks were created to replace that code by XML configuration files, configuration by code, or .NET attributes. The basic idea is the same though.

Examples of dependency injection frameworks for .NET: AutoFac, Castle, Spring.NET, StructureMap, Ninject and the Managed Extensibility Framework.