Question

我使用什么来创建使用Entity Framework的新地址：

OP1：

IRepository<Address> _addressRepository;

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

Op2中：

public bool CreateAddress(AddressDto addressDto);

与服务方法交谈以插入新地址。

问题是，在项目的长期维护中，哪一项更能保证不存在某人改变某些东西的风险并打破另一段依赖它的代码呢？

根据您的经验，哪一种是最好的方法？

Answer 1

根据我的经验，第二种选择效果最好。我喜欢有一个服务外观，在这个外观背后，业务逻辑可以以不会影响我的服务的消费者的方式实现和调整。顺便说一句，服务可以是域服务，Web服务，Web API等。基本上它是一个围绕业务逻辑和数据访问的shell，它只暴露了一些消费者可以调用的方法。

在我的视图中公开存储库方法会带来太多。为什么消费层会知道存储库实现？而且你将永远与存储库模式联系在一起。关于EF和（通用）存储库的讨论很多。就个人而言，我讨厌通用存储库。我喜欢用聚合根来思考。拥有每个实体类型的存储库通常是一层太多，它只会妨碍。 DbSet中的DbContext是基本存储库。上下文完全适合作为一个工作单元。我倾向于直接在服务方法中转向上下文，而不是编排存储库和工作单元。当然，可以使用存储库，但将它们隐藏在服务外观后面。

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

Answer 2

尝试使用这样的存储库：

 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
}

当您需要Adress的新实例时，只需致电您的存储库为您执行此操作：

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

使用AdressRepository只需：

adressRepository.Insert(yourAdressObject)

最后调用上下文的SaveChanges：

yourDataContext.SaveChanges();

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

2 个答案: