在 StartUp.cs 中引用 DbContext 打乱了我在 .NET Core 应用程序中的体系结构
Referencing DbContext in StartUp.cs is messing up my architecture in .NET Core app
我正在尝试提出一个可以正常流动的项目结构，但要让 运行 成为障碍。尤其是我不知道 EF 的 DbContext 应该放在哪里的地方。我不希望我的 API 引用我的数据层。我唯一能想到的是将 EntityFramework 安装到域层并让 DbContext 驻留在其中。
TestProj.Data Class 库 (.NET Core)
Entity Framework 已安装。包含 UnitOfWork class，Repositories 文件夹，其中包含进行数据库调用的所有存储库。还将包含 EF 迁移。对其业务实体的引用 TestProj.Domain。
TestProj.Domain Class 库 (.NET Core)
包含所有业务实体的模型文件夹、IUnitOfWork 接口和 TestProj.Data 中存储库的所有接口，即 ICustomerRepository。
TestProj.Api Web API 项目（.NET Core）
我认为这应该只引用 TestProj.Domain，但我还需要引用 TestProj.Data 以便在 StartUp.cs 中设置所有服务，即
services.AddDbContext<TestProjDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
services.AddTransient<IUnitOfWork, UnitOfWork>();
services.AddTransient<ICustomerRepository, CustomerRepository>();
这是我开始感到困惑的地方。
我的问题：
Api 项目可以同时引用域和数据项目吗？似乎我需要在 StartUp.cs
中设置依赖注入
我将所有内容的接口都放在 Domain 项目中是否正确？
TestProjDbContext 应该为 EF 坐什么项目？我最初的想法是数据项目？
DTOs/Pocos 之类的物品去了哪里？在 API 项目或 Domain 项目中？你假设 API 可以安装 AutoMapper，因为它引用 TestProj.Domain 可以将原始业务实体映射到 API.
中的 DTO
最后，业务逻辑去哪儿了？数据层和 API 之间的规则。我假设正确的位置是 TestProj.Domain。如果 API 只调用域中的业务逻辑而不是将 IUnitOfWork 注入我的 api 控制器，我可能会解决我的问题，我会注入 TestProj.Domain.Services.CustomerService。这有意义吗？
我对此的看法：
Is it alright for the Api project to reference both the Domain and Data projects?
我觉得没问题。
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?
我通常将 BlahBlahContext class 放入 Domain 项目
Where do items like DTOs/Pocos go? In the API project or the Domain project?
我为这个不同的项目做了，叫做 Dto。然后在需要的时候参考这个。
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.
我在解决方案中用于这个不同的项目 -> 称为服务
希望对您有所帮助。
我正在尝试提出一个可以正常流动的项目结构，但要让 运行 成为障碍。尤其是我不知道 EF 的 DbContext 应该放在哪里的地方。我不希望我的 API 引用我的数据层。我唯一能想到的是将 EntityFramework 安装到域层并让 DbContext 驻留在其中。
TestProj.Data Class 库 (.NET Core)
Entity Framework 已安装。包含 UnitOfWork class，Repositories 文件夹，其中包含进行数据库调用的所有存储库。还将包含 EF 迁移。对其业务实体的引用 TestProj.Domain。
TestProj.Domain Class 库 (.NET Core)
包含所有业务实体的模型文件夹、IUnitOfWork 接口和 TestProj.Data 中存储库的所有接口，即 ICustomerRepository。
TestProj.Api Web API 项目（.NET Core）
我认为这应该只引用 TestProj.Domain，但我还需要引用 TestProj.Data 以便在 StartUp.cs 中设置所有服务，即
services.AddDbContext<TestProjDbContext>(options => options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));
services.AddTransient<IUnitOfWork, UnitOfWork>();
services.AddTransient<ICustomerRepository, CustomerRepository>();
这是我开始感到困惑的地方。
我的问题：
Api 项目可以同时引用域和数据项目吗？似乎我需要在 StartUp.cs
我将所有内容的接口都放在 Domain 项目中是否正确？
TestProjDbContext 应该为 EF 坐什么项目？我最初的想法是数据项目？
DTOs/Pocos 之类的物品去了哪里？在 API 项目或 Domain 项目中？你假设 API 可以安装 AutoMapper，因为它引用 TestProj.Domain 可以将原始业务实体映射到 API.
中的 DTO最后，业务逻辑去哪儿了？数据层和 API 之间的规则。我假设正确的位置是 TestProj.Domain。如果 API 只调用域中的业务逻辑而不是将 IUnitOfWork 注入我的 api 控制器，我可能会解决我的问题，我会注入 TestProj.Domain.Services.CustomerService。这有意义吗？
我对此的看法：
Is it alright for the Api project to reference both the Domain and Data projects?
我觉得没问题。
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?
我通常将 BlahBlahContext class 放入 Domain 项目
Where do items like DTOs/Pocos go? In the API project or the Domain project?
我为这个不同的项目做了，叫做 Dto。然后在需要的时候参考这个。
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.
我在解决方案中用于这个不同的项目 -> 称为服务
希望对您有所帮助。