具有实体框架 6 的实用 DAL 层答案

【问题标题】：Utility DAL layer with entity framework 6具有实体框架 6 的实用 DAL 层
【发布时间】：2015-11-28 22:04:31
【问题描述】：

我想知道用 EF 制作 dal 层的实用性。为什么不直接在业务层调用 EF，考虑到 EF DBContext 是一个 unitOfWork 而 List DBSet 是存储库？那么为什么要添加一个额外的 DAL 层，这最终是一个门面.. 我看到的唯一优势是，如果我们必须更改数据访问实现，例如用 Hibernate 或其他替换 EF。但老实说，我从未见过这种情况发生。

【问题讨论】：

“直接在业务层调用 EF”——具体在哪里？在业务对象本身？作为运行业务用例的服务/事务脚本的一部分？在位于业务层的单独的类似存储库的对象中？
@guillaume31，不是业务对象本身，而是来自服务。例如： public OrderService(IOrderRepository repo) { this.repo = repo } public void Save(OrderDTO order) { var OrderEntity = ConvertDTOToEntity(order); if(OrderEntity.CheckBusinessRules()) repo.Save(OrderEntity) }
programmers.stackexchange.com/questions/235094/…

标签： c# architecture entity-framework-6 repository-pattern data-access-layer

【解决方案1】：

实际上，使用数据映射器开发 DAL 的必要性毫无用处，因为它包含 0 行代码。

数据映射器之上的一切都不是数据访问层，而是实际的域，因为像 OR/M 这样的数据映射器实现会将您的对象转换为底层关系数据，反之亦然，并且你在它们之上工作是为了开发你的领域，并错过对象关系阻抗的痛苦。

在数据映射器之上引入 存储库模式 的意义在于，从长远来看，您都希望能够将底层数据存储切换到非关系数据存储（也，从 NoSQL 切换到 SQL，谁知道！），还有另一个明确的原因在您的软件中引入存储库层：因为您希望能够使用假数据模拟数据存储以便对您的域进行单元测试。

最后，即使 Entity Framework 实现了工作单元和其他模式，有时它们的实现可能不适合您自己的领域要求，您需要将它们包装起来，以便为您的领域提供更多的具体性。

【讨论】：

同意模拟，但我认为切换基础数据仍然不常见，并不能证明花费 20% 的额外时间是合理的
@BobyOneKenobi 今天加班，明天加班；）
@bobyonekenobi 顺便说一句，如果您知道如何以 DDD 方式编写代码，您不需要 20℅ 额外时间。如果这是您第一次实施 DDD，可能会因为存在学习曲线而浪费时间......