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

debugcn 发表于 Dev

法兰瓦

我将Entity Framework Core for MySql与数据库优先方法结合使用。

搭建好数据库后，它会生成上下文类：sakilaContext.cs（sakila是MySql中的内置数据库/方案，我可以在其中玩耍）。

我将数据库注入了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;
}

就是好奇而已，

在这种情况下，注入具体的实现是错误的吗？
如果是这样，我怎么能只注入一个接口而不是注入一个具体的实现？

谢谢

埃里克·飞利浦

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

这要看情况。如果您要编写一个具有不同关注点（业务逻辑，验证，授权）的多层应用程序，还是要编写一个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实现了一个未与实体框架耦合的接口。