내 DB 컨텍스트 계층 (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" });
}
...
}
dbContext
save를 사용하기 위해이 ef core 2 CarContext
를 추상화하는 방법
나는 인터페이스 만들려고 IDbContext
에 의해 구현되는 CarContext
하지만 사용할 수없는 그런 식으로 dbContext.Cars.Insert
내가 EF 핵심 메서드와 속성에 대한 액세스 권한이없는 dbContext 자동차 컬렉션을 구현하고 있지 않다 때문입니다.
물론 구체적인 구현을 사용할 수 있지만 추상화를 시도하여 단위 테스트를 사용할 수 있습니다 ...
어떻게 하시겠습니까?
먼저 단위 테스트를위한 추상화가 필요하지 않습니다. EF Core는 100 % 테스트 친화적입니다. 둘째, EF (또는 실제로 모든 ORM)에 대한 필자의 견해로는 유일하게 수용 가능한 추상화는 마이크로 서비스 또는 CQRS / 이벤트 소싱 패턴입니다. 이들은 실제로 의존성을 완전히 추상화하거나 실제 업무 문제를 해결한다는 점에서 가치를 더합니다. 그러나 이러한 패턴은 또한 올바르게 구현하기 위해 상당한 노력이 필요하며, 일반적으로 크고 복잡한 응용 프로그램을 위해 예약되어 있습니다.
길고 짧은, 당신이 정말로 좋은 이유가 없다면 EF를 직접 사용하십시오. 테스트는 좋은 이유가 아닙니다.