.Net核心实体框架抽象

时间:2017-11-14 16:43:45

标签: c# entity-framework interface repository-pattern dependency-management

我有一个 .Net核心类库项目,它有一个使用Entity Framework的上下文文件。上下文文件如下所示;

public partial class Qcrr : DbContext
{
    public virtual DbSet<AirWorthyNess> AirWorthyNess { get; set; }
    public virtual DbSet<AwLog> AwLog { get; set; }
    public virtual DbSet<AwserialNumbers> AwserialNumbers { get; set; }
    public virtual DbSet<EmployeeInformation> EmployeeInformation { get; set; }
    public virtual DbSet<Password256> Password256 { get; set; }
    public virtual DbSet<Persistant> Persistant { get; set; }
    public virtual DbSet<TblApplicationRights> TblApplicationRights { get; set; }

    protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    {
        if (!optionsBuilder.IsConfigured)
        {
            optionsBuilder.UseSqlServer(@"my connection string");
        }
    }

    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        /* my tables
        .
        .
        .

        */
    }
}

现在,我还有一个简单的 .Net核心控制台应用程序,它引用了类库 dll 以进行测试。我希望能够在我的控制台应用程序中使用EF DbSet功能,因为它,而无需再次引用EF。当然,如果我尝试直接使用上下文文件,我有以下错误;

enter image description here

它告诉我再次引用实体框架。

所以我的问题是,抽象我的类库中的dbcontext的最佳实践方法是什么?

我是否需要实现DbContext功能(如Add,AddRange,Delete,IQueryable实现(Select,Where,First ...))?

1 个答案:

答案 0 :(得分:0)

实体框架已经是DB的一个很好的抽象。 如果添加另一个图层,则总是会被迫为您的抽象添加越来越多的功能。

很好的例子是EF的AsNoTracking功能。它对性能有好处,但是在不重新实现整个EF逻辑的情况下将它的实现添加到您的抽象中是一件大事。另一个例子是空间数据类型,原始SQL查询以及业务逻辑可能需要的更多有趣功能,但由于您的抽象,您无法使用它们。所以不要添加另一层。

在我看来,解决方案是使用Repository模式。