抽象 ef core 2 dbContext
我正在尝试对我的数据库上下文层进行抽象(EntityFramework 2.0).
I'm trying to make an abstraction over my DB Context layer (EntityFramework 2.0).
Car.DataContext
-------------------
public abstract class BaseCarContext : DbContext
{
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
modelBuilder.Entity<Car>(e =>
{
e.ToTable("Car");
});
modelBuilder.Entity<Car>(e => { e.ToTable("Cars"); });
}
}
public class CarContext : BaseCarContext
{
protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
{
if (optionsBuilder.IsConfigured)
return;
optionsBuilder.UseSqlServer(@"Server = xxxx; Database = xxxx; Trusted_Connection = True;");
}
public DbSet<Car> Cars { get; set; }
}
Car.Logic
----------------
public interface ICarService
{
GetCarResponse RetrieveCar(int id);
void Save(int id);
...
}
public class CarService : ICarService
{
private readonly ICarService service;
// dbContext interface
public CarService(ICarService service){
this.service = service;
// injecting db context interface
}
public void Save(int id){
... saving using injected db context
// injected db context.Insert(new Car{ Name = "Honda" });
}
...
}
我如何抽象这个 ef core 2 CarContext
以便使用 dbContext
保存
How can I abstract this ef core 2 CarContext
in order to use dbContext
save
我试图制作一个由CarContext
实现的接口IDbContext
但那样我就不能使用 dbContext.Cars.Insert
因为我没有实现 dbContext 汽车集合无法访问 ef 核心方法和属性.
I tried to make an interface IDbContext
which is implemented by CarContext
but that way I cannot use dbContext.Cars.Insert
because I'm not implementing dbContext cars collection don't have access to ef core methods and properties.
我当然可以使用具体的实现,但我正在尝试进行抽象,以便我可以使用单元测试,...
I can use of course concrete implementation but I'm trying to make an abstraction so I can use unit tests, ...
你会怎么做?
首先,单元测试不需要抽象.EF Core 100% 测试友好.其次,在我看来,对于 EF(或真正的any ORM)来说,唯一真正可接受的抽象要么是微服务,要么是 CQRS/事件源模式.这些实际上增加了价值,因为它们要么完全抽象依赖项和/或解决实际的业务线问题.但是,这些模式也需要付出大量努力才能正确实施,因此,通常是为大型复杂应用程序保留的.
First, you don't need an abstraction to unit test. EF Core is 100% test-friendly. Second, the only truly acceptable abstractions, in my opinion for EF (or really any ORM) is either a microservice or the CQRS/event sourcing patterns. Those actually add value in that they either fully abstract the dependency and/or solve real line-of-business problems. However, those patterns also require a significant amount of effort to implement correctly, and as such, typically are reserved for large, complex applications.
总而言之,除非您有充分的理由不使用,否则只需直接使用 EF.测试不是一个很好的理由.
Long and short, just use EF directly unless you have a truly good reason not to. Testing is not a good reason.