CODEWITHSUNDEEP
c#.netentity-frameworkdependency-injectionasp.net-core
g_b
g_b

Reputation: 12438

Several questions trying out n-tier with ASP.NET 5/EF7 using Dependency Injection

My current setup is like this: Presentation (ASP.NET MVC) -> Service (Web API) -> Business Logic -> DAL. I am trying out Dependency Injection so I am not too familiar yet on how it should be implemented.

Right now, I am having trouble in passing the dependency in my setup. This is the code:

In BLL:

public class StudentLogic : IStudentLogic
{
    private IStudentRepository _studentRepository;

    public StudentLogic(IStudentRepository repo)
    {
        _studentRepository = repo;
    }

    //  Some codes ommitted
}

In DAL:

public class StudentRepository : IStudentRepository
{
    private TestDbContext _context;

    public StudentRepository(TestDbContext context)
    {
        _context = context;
    }
}

So I have this at the BL layer which is called by a Web API in the Service Layer. The problem is since the constructor takes an IStudentRepository, I am forced to reference the DAL in the Service Layer since I need to pass an I IStudentRepository in the StudentLogic constructor which is called in the Service Layer. I think I'm doing it wrong so my questions are:

  1. How do I resolve the dependency without referencing DAL in service layer? I think I need to use IoC container but I am not sure how.

  2. If question 1 is resolved, then it means I am able to call StudentLogic with the passed IStudentRepository. The StudentRepository needs to have a DbContext passed also in its constructor so I can do transactions. How do I resolve this context also.

An example would be very helpful. I understand DI but so far, i have only use manual injection so I am not sure how to do this using an IoC.

Upvotes: 0

Views: 364

Answers (1)

Dan
Dan

Reputation: 1018

Unfortunately someone somewhere will have to know how to connect the dots. Ideally this will only happen at the entry point of your application (WebApi or Integration tests).

It is still possible to achieve a good level of data persistence abstraction.

Try taking the Onion Architecture approach.

http://jeffreypalermo.com/blog/the-onion-architecture-part-1/

In short your application stack will look something similar to:

     WebApi           Integration
      (UI)               Tests
       |___________________|
                |
       _________|__________
       |                   |
  Application       Infrastructure
 Service Layer      Service Layer
     (BLL)              (DAL)
       |__________________|         
                | 
                |
          Domain Model
              Layer

Your IStudentRepository along with (I assume) your Student object will be housed in the Domain Model Layer.

The Implementation of your IStudentRepository in the Infrastructure Layer.

Finally the StudentLogic service in the Application Service Layer.

This gives you the ability to implement many Infrastructure projects specific to the data access method you chose. In this instance EntityFramework however you may wish to have an Azure Blob Storage data persistence project or abstract an external api wrapper into its own infrastructure project.

Each infrastructure project can exist in its own

This decouples the knowledge of your data persistence from the "Core" of your application.

(WebApi -> Application Services -> Domain Model)

Upvotes: 2

Related Questions