locked
Dbcontext - Business Layer or Data Access Layer? RRS feed

  • Question

  • User1900576753 posted

    Hello,

    I am developing an application using ASP.NET MVC and Code First. I have separate projects for UI, Domain and Repository. UI has a reference to Domain and Domain has reference to Repository.

    I need to define the DbContext class. Which project this class should be part of? Logically I feel it should be Repository. But if I add it to Repository, there will be a cicrular reference between Domain and Repository (since Dbcontext will need reference to domain).

    Help is appreciated.

    Piyush

    Monday, May 23, 2011 7:01 AM

Answers

  • User-1179452826 posted

    You have your dependencies wrong. Why should the domain depend on the repository implementation? The domain should have the POCO entity classes and declare the repository interface. The repository implementation dll should reference the domain dll and provide the implementation. You can inject the appropriate instance of a repository instance from the UI (end client) into the domain via constructor injection. You can use an IOC container like Autofac, Ninject, unity etc. to help with this.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, May 23, 2011 8:05 AM

All replies

  • User-1179452826 posted

    You have your dependencies wrong. Why should the domain depend on the repository implementation? The domain should have the POCO entity classes and declare the repository interface. The repository implementation dll should reference the domain dll and provide the implementation. You can inject the appropriate instance of a repository instance from the UI (end client) into the domain via constructor injection. You can use an IOC container like Autofac, Ninject, unity etc. to help with this.

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Monday, May 23, 2011 8:05 AM
  • User1740762396 posted

    If the POCO's are define in the Domain layer, and the DbContext is in the Repository layer, then he needs to reference the Domain layer to get the POCO's to use in his repostitories.

    Actually, all three of these should be in separate assemblies. The POCO's, being simple datatype classes, should be in their own assembly, don't rely on any solution references, and can be used in all the other assemblies.

    The Domain assembly references both the POCO assembly and the Repository assembly. Thus, the domain can declare a repository.

    Ideally, for UOW purposes, the DbContext should also be in its own assembly. Then the Domain can inject it into a repository, and pass the dbcontext around to several different repositories before calling Save() on the context.

    Wednesday, July 10, 2013 3:17 PM
  • User-1179452826 posted

    If the POCO's are define in the Domain layer, and the DbContext is in the Repository layer, then he needs to reference the Domain layer to get the POCO's to use in his repostitories.

    Actually, all three of these should be in separate assemblies. The POCO's, being simple datatype classes, should be in their own assembly, don't rely on any solution references, and can be used in all the other assemblies.

    The Domain assembly references both the POCO assembly and the Repository assembly. Thus, the domain can declare a repository.

    Ideally, for UOW purposes, the DbContext should also be in its own assembly. Then the Domain can inject it into a repository, and pass the dbcontext around to several different repositories before calling Save() on the context.

    Why? Assemblies are units of deployment, namespaces units of logical separation. Solutions should look to solving business problems, not who gets injected into who and how.

    Wednesday, July 10, 2013 3:25 PM