.Net核心实体框架抽象

Question

I have an .Net Core Class Library project which has a context file that uses Entity Framework . The context file looks like this;

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
        .
        .
        .

        */
    }
}

Now, I also have a simple .Net Core Console Application that references the class library dll for testing purposes. I want to be able to use the EF DbSet functionality as it is , within my console app without having to reference EF again. Of course if I try to use the context file directly, I have the following error;

Its telling me to reference Entity Framework again.

So my question is, what would be the best practice approach to abstract my dbcontext which lies within my Class Library ?

Would I need to implement the DbContext functionalities (scuh as Add, AddRange, Delete, IQueryable implementations (Select, Where, First...))?

Answer 1

Entity framework is already a good abstraction for DB. if You add another layer, you always will be forced to add more and more functionality to your abstraction.

Good example is AsNoTracking function for EF. It is good for performance, but adding it's implementation to your abstraction without re-implementing whole EF logic is a big deal. Another example is Spatial data types, raw SQL queries and much more interesting functions that your business logic might require, but you can't use them, because of your abstractions. So don't add another layer.

In my opinion the solution is to use Repository pattern.