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

Posted 2023-02-24

【中文标题】是否可以在 Asp.net Core 解决方案的单独层中管理 DBContext 的注入

【英文标题】：Is it possible to manage injection of DBContext in separate Layer for Asp.net Core Solution

【发布时间】：2018-09-15 15:00:05

【问题描述】：

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

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

BLL

实体（模型和视图模型）

DAL（DBContext、存储库）

---

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

有没有办法真正将其分开，使得 web ui 项目在仍然使用 DI 时不需要引用 DAL (DBContext)？我知道要发生依赖注入，DBContext 需要在 web ui 启动时配置为范围服务，但从逻辑上讲，UI 需要引用或与达尔。

【问题讨论】：

可以在没有依赖注入的情况下做到这一点（即在需要时创建一个新实例），但不会获得上下文池的好处。

Web 项目是否引用 DAL 真的很重要吗？真正的问题是你的类在项目之间是松散耦合的。

可能不会，只是很难接受我的 Web UI 需要引用它并正在寻找任何可能的替代方案的想法。自从我的帖子以来，对 DI 和组合根有了更多的了解，我知道这必须在应用程序中进行管理。

【参考方案1】：

我建议使用这些层：

Web UI（具有验证属性的模型 - 数据格式、必需等） 服务 合同 DLL（接口 + 实体） 实施（控制器操作） 数据访问

在服务和 Web UI 之间共享合同 DLL。在服务内部使用您喜欢的任何 DAL / ORM。就个人而言，我更喜欢Dapper。

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

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

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

【讨论】：

澄清一下，网站、服务和合同是同一个 Visual Studio 解决方案中的三个独立项目。网站和服务在不同的端点上运行。