Dependency Injection in a 3 layer asp.net mvc application

Question

I have a 3 layer application and the layers are:

• Web: Presentation Layer (ASP.NET MVC) --> only sees BLL
• BLL: Business Logic Layer --> only sees DAL
• DAL: Data Access Layer

So the Web layer doesn't know anything about my DAL layer. I have repository interfaces and concrete classes in my DAL, which are used in BLL layer in business logic classes. The question is, in order to decouple DAL and BLL, how do I setup Ninject to inject my repository implementations to the BLL layer?

The same question is for Web layer and BLL layer, I have interfaces and implementations on BLL which I use them in Web layer, how should I setup Niject for this?

Solution 1

The idea is that you define interfaces for your DAL and BLL. You then take an instance of such an interface as a constructor parameter. Example

interface IDatabase
{
    // Methods here
}

Your BLL class:

public class Bll
{
    IDatabase _db;
    public Bll(IDatabase db)
    {
        _db = db;
    }

    public void SomeMethod()
    {
        // Use db here
    }
}

Then in your composition root (in the web application) you use the kernel to configure these dependencies:

 kernel.Bind<IDatabase>().To<ConcreteDatabase();

You need the same thing from your controllers to your BLL, but it works the same way.

Apart from that, I think your dependencies are not correctly set up. In general you don't want these vertical dependencies. You should aim for a flatter hierarchy. I wrote a blog post about this: http://www.kenneth-truyers.net/2013/05/12/the-n-layer-myth-and-basic-dependency-injection/

In my blog post I explain what the problem is with such a hierarchy and how you can avoid it. Apart from that, it describes exactly your problem: ASP.NET MVC, BLL, DLL and Ninject to tie it together.

Solution 2

We faced this issue in our enterprise level application as well. How do you load up your dependency injection engine with classes from your business and data tiers without creating hard references to the business and data tiers from your web application. We played with a few designs initially and came up with this very successful design which has worked for us for 18 months in production so far and performs very well.

In the ninjectwebcommon file in your web application, use reflection to access your business and data tiers so that you can load up everything needed

Like so:

        System.Reflection.Assembly assembly;

        assembly = System.Reflection.Assembly.Load("our.biztier");
        kernel.Load(assembly);

        assembly = System.Reflection.Assembly.Load("our.datatier");
        kernel.Load(assembly);

Ninjects "Load" method looks for any class in the assembly which inherits the ninject class "NinjectModule" and then calls it to load everything into the kernel.

So our business and data tiers each contain one simple injection class which we use to load up everything.

public class InjectionModuleBiz : NinjectModule
{


    public override void Load()
    {
        Kernel.Bind<ICustomerBiz>().To<CustomerBiz>().InRequestScope();
        Kernel.Bind<IEmployeeBiz>().To<EmployeeBiz>().InRequestScope();
    }
}

and we have another injectionModule class in our data tier

public class InjectionModuleData : NinjectModule
{


    public override void Load()
    {
        Kernel.Bind<ICustomerData>().To<CustomerData>().InRequestScope();
        Kernel.Bind<IEmployeeData>().To<EmployeeData>().InRequestScope();
    }
}

The end result is that all of our business tier and data tier classes are loaded up in our ioc container and can be injected anywhere.

Hope that helps.

Solution 3

I agree there is lots of confusion when we use Dependency injection in N-Tier applications using Visual Studio.

Mainly because in Visual Studio we structure layers as different projects in a solution and adding the dependencies by referring the project or DLL. This is quite different than the principles of DI and Composition Root concepts.

The basic question is what dependencies we are injecting ?

Business Logic or Repository ?

If it is repository , yes you are right , the web layer need not be knowing about it. It is the BLL select the repository based on certain conditions.

If we have completely isolated applications we need to set up DI at two levels.

Your web application will needs to setup ninject to create your BLL components. The BLL application will setup ninject to create a specific set of logic and repository classes.

Comments

[clhereistian]

What have tried so far? The easiest thing to do it to feed the DAL interfaces to the constructors in your BLL, and then set up a Ninject module to inject the concrete classes. But I have a feeling you already know that.

[Mark Seemann]

For a start, please see blog.ploeh.dk/2013/12/03/…

[Ashkan]

@MarkSeemann: I read that, how the onion architecture could be applied to 3 layer application? In this architecture: UI --> Domain <-- DAL the inward dependencies are towards Domain which implies that DAL is on the outer layer of the onion, which is not true, DAL is the lowest level layer I think.

[Erik Funkenbusch]

@Ashkan - You are not fully understanding the point. DAL does NOT become the "lowest layer". You're confusing data flow with architecture. Yes, the data does flow "downward" and the database and DAL are at the bottom of a dataflow, but that doesn't mean it has to be architected that way.

[Ashkan]

OK, thanks. I guess I should keep reading on the subject...

[Ashkan]

Then in your composition root (in the web application) you use the kernel to configure these dependencies, The problem is in composition root I don't have the access to DAL interfaces and concrete classes.

[Kenneth]

If you structure your dependencies differently, you do. You should tie the web app to everything and all the rest to nothing. You can read my post to see why and how. It's a bit long to explain here (hence the post). If you have any question feel free to continue here

[clhereistian]

Are you using the Ninject MVC extension?

[Kenneth]

You can, although you could also do that yourself

[It's a trap]

In your blog post also, you will need to add reference to the DLL in your Web application Tier.