0

We're designing a layered business application in .net/c# and we are trying to follow the SOLID-principles as much as we see fit. Testability is very important in our project and for this purpose we are using Moq. Using moq we are, among other things, mocking our entity framework context.

As the main goal for our testing is the main business layer (BL) logic, the business layer classes can be injected with the Data Access Layer (DAL) context to use. See example below. sample constructor of a BL class responsible for loading data. This class injects dependencies for setting access, etc.

    public LoadDataProcess(KonstruktEntities context, IDataLoadedChecker dataLoadedChecker, ILoadUserBudgetData dataLoader, ISetLineAccess setBudgetLineStatus, ILineAccessFilterHandler budgetDataLineStatusFilterHandler) 
    {
        _context = context;
        _dataLoadedchecker = dataLoadedChecker;
        _dataLoader = dataLoader;
        _setBudgetLineStatus = setBudgetLineStatus;
        _budgetDataLineStatusFilterHandler = budgetDataLineStatusFilterHandler;
    }

Now, there are also other DAL dependencies that can be injected into our BL classes. Since these objects are beeing instanciated in the Service Layer (WCF) I don't like that DAL components can be injected.

Question is, should we be injecting DAL dependencies into BL classes at all?

JohanLarsson
  • 475
  • 1
  • 8
  • 23
  • If you're trying to apply SOLID to your business layer, do take a look at [this](https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=91), [this](https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=92) and [this](https://www.cuttingedge.it/blogs/steven/pivot/entry.php?id=95) article, since they can make a tremendous difference in maintainability and flexibility of your application. – Steven Nov 28 '14 at 09:06
  • will have a look at these, thanks. What do you think about the question I asked? – JohanLarsson Nov 28 '14 at 09:25

1 Answers1

1

Since your BL depends upon abstractions, your are adhering to the Dependency Inversion Principle (DIP). It's obvious that your business layer needs to communicate with the DAL; there's really no way around this, but since your are depending upon abstractions instead of low level components, this will be fine.

Steven
  • 166,672
  • 24
  • 332
  • 435
  • Ok, to further work for a DIP-medal, do you see a reason to wrap the "KonstruktEntities"-class in any way? It inherits from DbContext which is a IObjectContextAdapter – JohanLarsson Nov 28 '14 at 09:44
  • one problem I see is when I, in for example a WCF funktion in my Service Layer, need to inject a DAL dependency directly. It feels like I shouldn't instantiate any DAL objects in the Service Layer, but maybe that has to be done?! – JohanLarsson Nov 28 '14 at 09:45
  • @JohanLarsson: All your components should be instantiated in your [Composition Root](http://blog.ploeh.dk/2011/07/28/CompositionRoot/), nowhere else. Letting your code depend on the `DbContext` is always a violation of the DIP, but this is something you can't always prevent. You must query the database somewhere. – Steven Nov 28 '14 at 09:48
  • yep I know its hard to be totally SOLID. My Composition root is located in the Service Layer and it uses an IoC-container so I guess I'm doing things "good enough" then. Thanks for your input. final question, should I instantiate the context once and inject that very same context to all the dependant classes? This way the same context object gets reused in the whole graph – JohanLarsson Nov 28 '14 at 09:58
  • @JohanLarsson: It's impossible to conform 100% to the SOLID principles. Apply them where it makes sense. About injecting the DbContext, please read [this q/a](https://stackoverflow.com/questions/10585478/one-dbcontext-per-web-request-why). – Steven Nov 28 '14 at 10:01
  • ahh so I suppose that I will have one context per wcf-function then. This beeing one unit of work and all the interfaces that need the context will then be injected with this very same object. – JohanLarsson Nov 28 '14 at 10:10