C# 是否可以在Asp.net核心解决方案的单独层中管理DBContext的注入

我们的asp.net核心解决方案分为以下几层：

Web UI项目（3种不同的Web应用程序）

BLL

实体（模型和视图模型）

DAL（数据库上下文，存储库）

---

所有Web UI都将利用BLL提供的服务，BLL反过来将引用DAL来与数据接口。通常，DBContext的服务在启动类中配置

---

有没有一种方法可以真正地将其分离开来，这样web ui项目在仍然使用DI时就不需要引用DAL（DBContext）？我了解到，要进行依赖注入，需要在web ui启动时将DBContext配置为作用域服务，但从逻辑上讲，ui需要引用DAL或与DAL有任何关系对我来说毫无意义。

我建议使用以下层：

Web UI（具有验证属性的模型-数据格式、必填项等）

服务

• 合同DLL（接口+实体）
• 实施（控制器操作）

数据存取

在服务和web UI之间共享契约DLL。在服务内部，使用您喜欢的DAL/ORM。就我个人而言，我更喜欢

然后，使用生成JSON服务的C#代理。通过网站的启动类将Refit代理注入web控制器。将大部分业务逻辑放在服务控制器中，并从网站控制器调用它们。将网站控制器中的逻辑保持在最低限度

在这种设计中，web UI不了解数据访问层。如果愿意，可以将其从Dapper切换到实体框架。Refit+a JSON服务为您提供了两端（web和服务）类型安全C#代码的好处，以及在需要时编写原始HTTP帖子的灵活性（例如，从web浏览器中运行的AJAX代码）

---

您还可以编写C#或PowerShell实用程序来利用该服务。换句话说，网站不必是服务的唯一消费者。

可以在没有依赖注入的情况下做到这一点（即在需要时创建一个新实例），但不会获得上下文池的好处。如果web项目引用DAL，这真的很重要吗？真正的问题是，您的类在项目之间的耦合度很低。可能不是，只是我很难接受我的Web UI需要引用这个概念，并且正在寻找任何可能的替代方案。自从我发表文章以来，我对DI和组合根有了更多的了解，我知道这必须在应用程序中进行管理。为了澄清，网站、服务和合同是同一VisualStudio解决方案中的三个独立项目。网站和服务在不同的端点上运行。