How can i decouple this project

Question

I have a scenario where my business layer has a direct reference in the form of a dll to my database layer which is acting as the repository in this project, now this means there is a direct dependancy on the database layer which would need decoupling, please see structure below:

I know how to use DI and containers for this, but i would like some tips and how to decouple this in some form without having to add a IRepository interface in the business layer and the database layer having concrete repositories calling the irepository in the business layer. Does this make sense at all.

I have a repository interface which sits in the Database_Layer dll :

 public interface IRepository
 {
    Task Add(Object item);

    Task Remove(int id);

    Task<Object> Find(int id);

    Task UpdateAsync(Object item);

    Task<IEnumerable<Object>> GetAllAsync();

    Task<IEnumerable<Object>> GetAllAsync(Object id);
}

Then i have a class in the Business tier called ContentPanel :

using Database_Layer.Interfaces;
namespace Business_Tier.Concrete
{
public class ContentPanel : IPanel
{
    IRepository _repository;
    public ContentPanel(IRepository repo)
    { 
        this._repository = repo;
    }

    public IResolver _Resolver { get; set; } = null;
    public IResolver Resolver { get => _Resolver; set => _Resolver.Resolve<IRepository>("ContentRepository",_repository); }

    public void Delete_Content_Panel(int id)
    {

    }

}

I want to eliminate the using reference the database_layer.interfaces and just resolve the repository dependancy, would i have to define the repository interface in the Business layer, in order to do this?

You don't have clear understanding about how DI works and why interfaces are important here. If you have any approach thought of doing DI with concrete class please try implementing it and tell us what issue you face in that. — Chetan, Mar 02 '18 at 12:07
Decoupling things doesn't necessarily mean removing entire references - at that point you're looking at plugins etc, which is another topic entirely. — James Thorpe, Mar 02 '18 at 12:11
but there is a direct dependancy on the database layer in the Business layer would you not agree with that. — tecman134, Mar 02 '18 at 12:21
See [Ioc/DI - Why do I have to reference all layers/assemblies in entry application?](https://stackoverflow.com/q/9501604/181087) — NightOwl888, Mar 02 '18 at 16:53

MrVoid · Accepted Answer · 2018-03-02T12:17:44.203

1

You business layer(dll) have a dependency on your data access layer(dll)

You need to use an interface to abstract the business layer contract from the data access implementation

Using DI in the Startup project will allow you to inject the desired implementation to that interface

You business layer will have always a physical dependency in the data access layer but will not have a dependency in the data access implementation.

edited Mar 02 '18 at 12:17

answered Mar 02 '18 at 12:11

MrVoid

709
5
19

i get the startup resolving of the dependancy, but how can i get rid of the dll dependancy, data access implementation would be the concrete repositories – tecman134 Mar 02 '18 at 12:20
so essentially it doesnt really eliminate the physical dependancy though does it? – tecman134 Mar 02 '18 at 12:26
No it does not, think about it, you need to pull data right? so you need a bridge to that data pulling. – MrVoid Mar 02 '18 at 12:29
The point of using interfaces is to hide implementation so your business layer does not know about how things are done. – MrVoid Mar 02 '18 at 12:30
hidden implementations got it, ok, so here is my two cents then from this learning exercise, essentially i register and resolve all my dependants in the startup right, and then in this scenario i can use the DataBase.Interfaces namespace which is calling the iRepositry and resolve it in the contentPanel class in the Business layer using the registered service in the startup right? – tecman134 Mar 02 '18 at 12:33
Yeah thats right, you use your interface in the business layer, injecting the concrete from the startup proejct – MrVoid Mar 02 '18 at 12:35
I know where do you come from and where do you want to go, so to save to you some pain, if you want to get better at this, read, practice and repeat – MrVoid Mar 02 '18 at 12:38
SOLID (object-oriented design) and Test-driven development (TDD) should be a good point to start – MrVoid Mar 02 '18 at 12:40
so essentially, what i have currently is correct and in line with seperation of concerns as well, only thing is resolving the dependancies – tecman134 Mar 02 '18 at 12:46
yes i have a scenario where my entire business tier is unit testable and i can pass mocked objects as domain objects – tecman134 Mar 02 '18 at 12:47
Yeah yo do, but sometimes is difficult to identify theory from the practical example, good luck mate, this is way to long :) – MrVoid Mar 02 '18 at 13:53

How can i decouple this project

1 Answers1