.Net Core 中的通用存储库模式与实体框架有什么相关性

Question

我正在尝试（但未能）理解通用存储库模式在包裹实体框架或 EF Core 的特定实例中的用途。

写这个有什么好处：

public void Update(T obj)
{
    DbContext.Set<T>().Attach(obj);
    DbContext.Entry(obj).State = EntityState.Modified;
    DbContext.SaveChanges();
}

当你通过简单地写成相同或更多的东西时

public void Update(Movie obj)
{
    DbContext.Set<Movie>().Attach(obj);
    DbContext.Entry(obj).State = EntityState.Modified;
    DbContext.SaveChanges();
}

或者

public void Update(Movie obj)
{
    var movie = DbContext.Movies.FirsOrDefault(x => x.MovieId == obj.MovieId);
    DbContext.Entry(movie).CurrentValues.SetValues(obj);
    DbContext.SaveChanges();
}

我想我真正的问题是为什么我们要围绕基本上已经是通用存储库（具有更多功能和优化）的通用存储库进行包装？

Answer 1

不想太自以为是，我想根据评论线程回答我自己的问题。

通用存储库模式是对象关系映射器 (ORM) 时代之前的遗留物，例如 Entity Framework、xHibernate、Dapper、PetaPoco 和其他上百万种映射器。

随着 ORM 的出现，存储库模式中的所有功能都封装在 ORM 本身中。

例如，每次调用.SaveChanges()DbContext 时，实体框架默认都会使用 Transaction/UnitOfWork。

它还会自动跟踪对查询返回的实体所做的更改，除非您明确告诉它不要这样做UseQueryTrackingBehavior(QueryTrackingBehavior.NoTracking)。

就通用存储库而言，您认为以下代码是什么：

MyDbContext.Set<WeatherForecast>().Add(forecast);