I am trying to come up with a project structure that will flow properly, but keep running into road blocks. Especially one where I can't figure out where DbContext for EF should go. I don't want my API referencing my Data layer. The only thing I can think of is installing EntityFramework to Domain layer and having the DbContext reside in there.
TestProj.Data Class Library (.NET Core)
Entity Framework is installed. Contains UnitOfWork class, Repositories folder with all repositories that make database calls. Will also contain EF Migrations. References TestProj.Domain for its Business Entities.
TestProj.Domain Class Library (.NET Core)
Models folder with all business entities, IUnitOfWork interface and all of the interfaces for the repositories in TestProj.Data i.e. ICustomerRepository.
TestProj.Api Web API Project (.NET Core)
I believe this should only be referencing TestProj.Domain, but I need to reference the TestProj.Data also in order to setup all of the services in StartUp.cs, i.e.
services.AddDbContext<TestProjDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
services.AddTransient<IUnitOfWork, UnitOfWork>();
services.AddTransient<ICustomerRepository, CustomerRepository>();
This is where I start getting confused.
My questions:
Is it alright for the Api project to reference both the Domain and Data projects? Seems like I need to in order to setup dependency injection in StartUp.cs
Is it correct that I am putting the interfaces for everything in the Domain project?
What project should the TestProjDbContext sit for EF? My initial thought was the Data project?
Where do items like DTOs/Pocos go? In the API project or the Domain project? U an assuming the API can have AutoMapper installed and since it references TestProj.Domain in can map the original business entities to the DTOs in the API.
Finally, where does business logic go? Rules in between the Data layer and the API. I am assuming the proper place is TestProj.Domain. Maybe this would fix my issue if the API only makes calls to the business logic in the domain instead of injecting IUnitOfWork into my api controllers I would inject TestProj.Domain.Services.CustomerService. Does this make sense?
My opinion on this:
Is it alright for the Api project to reference both the Domain and Data projects?
It's OK for me.
Is it correct that I am putting the interfaces for everything in the Domain project?
YES
What project should the TestProjDbContext sit for EF? My initial thought was the Data project?
I usually place BlahBlahContext class into Domain project
Where do items like DTOs/Pocos go? In the API project or the Domain project?
I made for this different project, called Dto. and then referenced on this when needed.
U an assuming the API can have AutoMapper installed and since it references TestProj.Domain in can map the original business entities to the DTOs in the API.
Sure
Finally, where does business logic go? Rules in between the Data layer and the API.
I use for this different project in solution -> called Services
Hope this helps.