Rhino Mocks, Dependency Injection, and Separation of Concerns
- by whatispunk
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?
