避免将具体的数据库上下文类注入控制器

Question

我正在使用 Entity Framework Core for MySql 和数据库优先方法。搭建好数据库后，生成上下文类：sakilaContext.cs（sakila是MySql内置的数据库/scheme，我用来玩玩的）。我在 Startup.cs 中注入了我的数据库public void ConfigureServices(IServiceCollection services)    {        services.AddMvc().SetCompatibilityVersion(CompatibilityVersion.Version_2_2);        var connectionString = @"server=localhost;port=1123;user=root;password=xxx;database=sakila";        services.AddDbContext<sakilaContext>(options => options.UseMySql(connectionString));    }在我的 api 控制器中，我这样做：private sakilaContext dbCtx;public SakilaController(sakilaContext dbContext){    dbCtx = dbContext;}只是个小疑问，在这种情况下注入具体实现是错误的吗？如果是，我怎么能只注入一个接口而不是注入一个具体的实现呢？

Answer 1

在这种情况下注入具体实现是错误的吗？

这取决于。如果您正在编写一个具有分离关注点（业务逻辑、验证、授权）的多层应用程序，或者您正在编写一个 5 页的应用程序来为有限数量的用户显示杂项信息？

我已经为小型的、主要是只读的应用程序完成了这些，因为只有很小的变化，我不需要过度设计和构建解决方案。

如果是，我怎么能只注入一个接口而不是注入一个具体的实现呢？

当然，但是在某些时候，一个类将需要一个 dbcontext，它可以由需要它的对象进行 DI 或创建。如果您确实将数据访问抽象到一个单独的类/接口中，我不会推荐 DI（将上下文注入具体的数据访问），因为该具体类型将与 EF 紧密耦合。这意味着如果您决定切换到 Dapper、NHibernate 或其他一些 ORM，您无论如何都必须重写所有方法。

一种快速而肮脏的方法（对于小型/学习经验，我永远不会向百万用户系统推荐这种方法）来抽象掉它DbContext很简单：

public interface IUserDA

{

  IQueryable<User> Users { get; }

}

public class MyDbContext : IUserDA

{

  public DbSet<User> Users { get; set; }

  IQueryable<User> IUserDA.Users

  {

     get

     {

        return Users;  // references the DbSet

     }

  }

}

现在您的 MyDbContext 实现了一个未耦合到实体框架的接口。

但是如果我们注入一个具体的类，它会破坏 DI 的目的吗？

取决于你的目的。您究竟希望通过使用 DI 实现什么？您真的要编写真正的单元测试吗？您真的看到自己为多个安装/租户更改或拥有多个接口实例吗？

Answer 2

我不建议将 Entity Framework 抽象出来，因为它本身已经是一个抽象（您可以在您的消费类不知情的情况下将数据库提供程序从 SQL Server 换成 PostgreSQL）。我也不建议将您的上下文注入您的控制器。

我喜欢做的是采用Command Pattern，利用令人惊叹的 Jimmy Bogard 库AutoMapper和MediatR，自己研究一下它是否合适。

为您提供一个基本示例，说明使用此类架构设计选择时控制器的外观：

[Route("api/[controller]")]

[ApiController]

public class SomeTypeController : ControllerBase

{

    private readonly IMediator mediator;

    private readonly IMapper mapper;

    public SomeTypeController(IMediator mediator, IMapper mapper)

    {

        this.mediator = mediator;

        this.mapper = mapper;

    }

    [HttpGet]

    public async Task<ActionResult<IEnumerable<SomeTypeContract>>> GetAll(CancellationToken cancellationToken)

    {

        var result = await mediator.Send(new GetAllSomeTypeRequest(), cancellationToken);

        return Ok(mapper.Map<IEnumerable<SomeTypeContract>>(result));

    }

}

我真的很喜欢这个，因为现在您的控制器充当业务逻辑的路由器。他们幸福地不知道引擎盖下究竟发生了什么（或者它是如何发生的）。

要了解问题的核心：

在这种情况下注入具体实现是错误的吗？

对此的答案有点固执己见，但许多人认为这不仅是一个可以接受的选择，而且是正确的选择。在某个时间点，为了进行实际的数据库查询，您需要了解您的 DBContext。

通过将其抽象出来，您只会通过编写数百种不同的方法来以不同的方式查询您的数据、执行各种操作而给自己带来selects痛苦includes。否则，您将拥有“笨拙”的方法，这些方法返回的数据比您实际需要的多得多。

通过具体了解您的 DBContext（如果您使用命令模式，可能在您的请求处理程序中），您可以完全控制数据的获取方式，允许查询优化以及强制关注点分离。

免责声明：我提出上述库是因为它们很棒且很有帮助，但我知道很多人看不起将它们包含在答案中。我只想说清楚，它们绝不是执行命令模式的必要条件，但如果您要采用它，为什么要重新发明轮子？