实体框架和 ASP.NET Core UOW 存储库模式答案

【问题标题】：Entity Framework and ASP.NET Core UOW Repository pattern实体框架和 ASP.NET Core UOW 存储库模式
【发布时间】：2020-06-02 21:03:51
【问题描述】：

我有一个 ASP.NET Core 应用程序，它分为三层，即：

数据访问层（实体框架）
业务逻辑层（工作单元，存储库模式）
ASP.NET MVC Web 应用程序

到目前为止，我一直习惯于在 .NET Framework 中开发应用程序，但是，在转向 Core 时，我发现两者之间存在显着差异。

首先，我使用数据库优先方法来初始化我的实体框架。这里我使用了脚手架方法，效果很好。

但是，我注意到 app.config 不再存在于我的任何库中，并且我的连接字符串已移至源代码中的方法，即：

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
//connection stuff here
}

与在 .net 框架中使用 EF 相比，我通常会使用位于我的 app.config 中的连接字符串，即：

public EFClass(string connString)
        : base(connString)
    {

这不能再做，我不得不在我的 MVC Web 应用程序中使用 appsettings.json，这有点搞砸了松散耦合我的应用程序的想法。

理想情况下，当我不再拥有 app.config 时，如何在数据访问层访问我的连接字符串？

此外，我已经阅读了几个地方，UOW 存储库模式有点多余，因为 .NET Core 应用程序中的 DbContext 也可以用于 DI？我应该摆脱我的 UOW 并直接将我的 DbContext 注入我的存储库吗？

我的问题可能是错误的，因为我可能错过了这里的一些主要基础知识，但欢迎您为我指明更好的方向。

【问题讨论】：

查找 ioptions 和 iconfiguration 的东西。

标签： c# entity-framework asp.net-core

【解决方案1】：

EF 已经实现了 UoW 模式 - DbSets 是您的存储库，DbContext 是您的工作单元。您希望在插入/更新/删除特定实体时强制执行的过滤器和逻辑都可以在您的 DbContext 实现中配置（一种或另一种方式）。如果我认为我不能信任开发人员直接使用DbContext，我更愿意创建一个 API。

在任何情况下，您都应该使用依赖注入将DbContext 的实现提供给应该有权访问它的任何类。运行 ASP.NET Core 应用程序时，您使用必要的配置选项注册您的实现（无论它们是什么 - 从您的配置文件或其他地方）。当单元/集成测试组件使用您的DbContext 时，您可以手动构造实例并传递给构造函数。

示例（来自this）：

public void ConfigureServices(IServiceCollection services)
{
    ...

    // this method allows you to configure you DbContext options
    services.AddDbContext<YourDbContext>(options =>
        options.UseSqlServer(Configuration.GetConnectionString("DefaultConnection")));

    ...
}

【讨论】：

【解决方案2】：

你的 UoW 类的接口和类需要在构造函数上接收连接字符串。在您的 Startup 类内部的 ConfigureServices 方法中，您将获得 appsettings.json 的连接字符串。

 public void ConfigureServices(IServiceCollection services)
 {
     services.AddScoped<IUnitOfWork>(x => new UnitOfWork(strConnection));
 }

【讨论】：