Project dependencies using Ninject

Question

Continuing my studies in Dependency Injection, I have some doubt about the relationship between some projects and their dependencies.

enter image description here

I created the IocConfig class in App_Start folder

IocConfig class

public class IocConfig
{
    public static void ConfigurarDependencias()
    {
        IKernel kernel = new StandardKernel();

        kernel.Bind<IReceitaRepository>().To<SqlReceitaRepository>();

        DependencyResolver.SetResolver(new NinjectDependencyResolver(kernel));
    }
}

public class NinjectDependencyResolver : IDependencyResolver 
{
    private readonly IResolutionRoot _resolutionRoot;

    public NinjectDependencyResolver(IResolutionRoot kernel) 
    {
        _resolutionRoot = kernel;
    }

    public object GetService(Type serviceType)
    {
        return _resolutionRoot.TryGet(serviceType);
    }

    public IEnumerable<object> GetServices(Type serviceType)
    {
        return _resolutionRoot.GetAll(serviceType);
    }
}

But look at the below line

kernel.Bind<IReceitaRepository>().To<SqlReceitaRepository>();

I can't do a reference to SqlReceitaRepository because this class are in my Data Access Layer while App_Start folder and IocConfig are under Presentation Layer.

The IReceitaRepository are in my Interface project under Domain Layer and the implementation are in SqlReceitaRepository class under Data Access Layer.

I'm doing something wrong ? In my conception, I didn't have to do a reference to Data Access Layer at my Presention Layer.

Home Controller constructor

    private readonly IReceitaRepository repositorio;

    public HomeController(IReceitaRepository repositorio)
    {
        if (repositorio == null)
            throw new ArgumentException("repositorio");

        this.repositorio = repositorio;
    }

I'd be interested in this as well. I think there's generally a difference between "references" and "depends on" at least in some things i've read. If I remember correctly, your domain layer does not depend on any other layer correct? If that *weren't* the case I would say you could put your dependency resolver in that layer, which then gets called from presentation - but I don't think that works in this case because your domain layer does not depend on your data layer for setting up your DI. — Kritner, Aug 20 '14 at 14:05
@Kritner Correct, Domain layer hasn't dependencies with others layers. It's like in my drawing. I'm reading a book about dependency injection, and it's really interesting, but I'm with this doubt when using DI Container. — Lucas_Santos, Aug 20 '14 at 14:10

score 3 · Accepted Answer · answered Aug 20 '14 at 14:09

It depends, this is acceptable if you want a single point in your application to register all of your services. Something else you could do is add an API layer to your application which the domain and data access will use. This layer would contain all of your service interfaces so that they can be referenced across projects. Using this technique, you could then register your data layer services directly in this layer.

Both techniques have pros and cons. The first technique fits a more traditional application life-cycle where the application can decide which services it wants from the different module it uses. The second technique can be used when plugins are involved. In this case, the application does not know about all the services that are available and can delegate part of its initialization to the individual plugins.

As a side note, do not forget that dependency injection does not force you to use an IoC container. In the end, a simple method such as Buy(IProduct product) uses the DI pattern. It depends on a product that will be provided externally. What the IoC container does is simplify this process when using this pattern with services. It is not The Pattern.

@EttieneMaheu Yes this is really a very good point, the DI pattern don't need a DI Container, but when I was doing the "hard work" by myself, using `IController` and a `ControllerFactory`, sounds to me use a DI Container a easier way to do the same thing. And it's naturally in DI learning path, do it by myself using `IController` and at the end of the path we saw how DI Containers can do these hard work easier for us. — Lucas_Santos, Aug 20 '14 at 14:19
Exactly. My point was simply that you apply the pattern correctly here as you effectively inject your dependency within your controller even though it is directly referenced in your application startup process. :) — Etienne Maheu, Aug 20 '14 at 14:22

Project dependencies using Ninject

1 Answers1