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

Question

我有一个 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 直接注入我的存储库吗？

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

Answer 1

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

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

示例（来自此）：

public void ConfigureServices(IServiceCollection services)
{
    ...

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

    ...
}

Answer 2

UoW 类的接口和类需要在构造函数上接收连接字符串。 在启动类中的 ConfigureServices 方法中，您可以获得 appsettings.json 的连接字符串。

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