Project dependencies using Ninject

Question

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

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;
    }

Answer 1

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.