c# - 向服务层公开 Entity Framework 扩展

Question

我已经使用 IRepository 实现了我的数据层图案。这些方法之一返回 IQueryable :

public virtual IQueryable<TEntity> Queryable()
{
        return dbSet;
}

我还有一个服务层调用这个提供过滤的方法，例如:

public User GetByName(string name)
{
    return _repository.Queryable()
        .Where(a => a.Name == name)
        .ToList();
}

到目前为止一切顺利， Entity Framework 仅在数据层引用，服务层对此一无所知。

现在，我还想做两件事:

1. 使用Include方法
2. 使用ToListAsync()方法

所以现在我的服务方法如下所示:

public async Task<User> GetByName(string name)
{
    return await _repository.Queryable()
        .Where(a => a.Name == name)
        .Include(x => x.Pets)
        .ToListAsync();
}

现在的问题是Include()和 ToListAsync()都在 System.Data.Entity 中EntityFramework.dll 中的命名空间.

我不想从我的服务层中引用 EF，它不应该关心或知道这一点，但看不到在保持架构清洁的同时解决这个问题的其他方法。我能看到的唯一解决方案是:

1. 将 Entity Framework 添加到服务层
2. 向包装 UserData 的数据层 ( IRepository<User>' and handles the two additional methods required. The service will then take use an instance of this rather than) 添加一个新类IRepository`。

关于我如何在仍然坚持最佳实践的同时解决这个问题的任何建议？

Answer 1

我知道您想根据最佳实践在存储库层抽象掉 EF。但是您的用例(这里是您的主要问题)与此矛盾 - 您想要向您的服务层公开 EF 提供的所有内容。

听起来您需要就此存储库的职责定义一个严格的界限。如果要返回 IQueryable，那么包装 EF 有什么好处呢？您是否计划在生产中实际使用其他一些存储库实现？如果是这样，当您公开 IQueryable 时，将很难确保两种 repo 类型都是正确的。这就是您现在看到的痛点。

在我看来，存储库应该定义您获取数据的方式。它应该公开返回实际模型的简单调用，例如 GetAllUsers。当您让业务/服务层定义自己的方式来获取数据时，它会使存储库变得多余。