用于在数据库中插入数据的存储库或服务-实体框架

本文关键字：服务 框架 实体 存储 数据库 插入 数据 用于 | 更新日期: 2023-09-27 18:04:39

如何使用实体框架创建新地址:

Op1: 

IRepository<Address> _addressRepository;

并使用地址实体直接与数据库对话。

《凤凰社》第2章:

public bool CreateAddress(AddressDto addressDto);

与service方法对话以插入新的Address。

问题是，在项目的长期维护中，哪一个提供了更多的保证，不存在某人更改某些内容并破坏依赖于它的另一段代码的风险?

根据你的经验，哪一个是最好的方法?

用于在数据库中插入数据的存储库或服务-实体框架

根据我的经验，第二种方法效果最好。我喜欢有一个服务框架，在它的背后可以实现和调整业务逻辑，而不会影响到我的服务的消费者。顺便说一下，服务可以是域服务，web服务，web API。基本上，它是一个围绕业务逻辑和数据访问的外壳，只是公开了一些消费者可以调用的方法。

在我的视图中公开存储库方法泄露了太多信息。为什么消费层要知道存储库实现?您将永远与存储库模式绑定在一起。有很多关于EF和(通用)存储库的讨论。就我个人而言，我讨厌通用存储库。我喜欢从集合根的角度来思考。为每一种实体类型都设置一个存储库通常是一层太多了，它只会碍事。DbContext中的DbSet s是基本库。上下文完全适合作为一个工作单元。我倾向于直接在服务方法中使用上下文，而不是编排存储库和工作单元。当然，你可以使用存储库，但是要把它们隐藏在服务面板后面。

最后一点:我不会从服务方法返回一个布尔值，而是一个包含方法失败/成功信息的对象。例如:Web API中的HttpResponse

尝试像这样使用存储库:

 public class Repository<T> : IRepository<T> where T : class
{
    protected DbSet<T> DbSet;
    public Repository(DbContext dataContext)
    {
        DbSet = dataContext.Set<T>();
    }
    #region IRepository<T> Members
    public void Insert(T entity)
    {
        DbSet.Add(entity);
    }
    public void Delete(T entity)
    {
        DbSet.Remove(entity);
    }
    public IQueryable<T> SearchFor(Expression<Func<T, bool>> predicate)
    {
        return DbSet.Where(predicate);
    }
    public IQueryable<T> GetAll()
    {
        return DbSet;
    }
    public T GetById(int id)
    {
        return DbSet.Find(id);
    }
    #endregion
}

当你需要一个新的address实例时，只需调用你的Repository来为你做这个:

var adressRepository = new Repository<Adress>(yourDataContext);

对于addressrepository只需执行:

adressRepository.Insert(yourAdressObject)

最后调用上下文的SaveChanges:

yourDataContext.SaveChanges();
相关文章：