2

我用什么来使用实体框架创建新地址：

操作1：

IRepository<Address> _addressRepository;

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

操作2：

public bool CreateAddress(AddressDto addressDto);

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

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

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

4

2 回答 2

1

根据我的经验，第二种选择效果最好。我喜欢有一个服务外观，在它后面可以以一种不会影响我的服务消费者的方式实现和调整业务逻辑。顺便说一下，服务可以是域服务、Web 服务、Web API 之类的东西。基本上，它是一个围绕业务逻辑和数据访问的外壳，只公开一些消费者可以调用的方法。

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

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

于 2013-03-19T22:48:08.307 回答
0

尝试使用这样的存储库：

 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();
于 2013-03-19T20:06:58.040 回答