C# 具有实体框架6的实用DAL层

我想知道使用EF制作dal层的实用性。

---

考虑到EF DBContext是一个工作单元，而List DBSet是存储库，为什么不在业务层直接调用EF呢？ 那么，为什么要添加一个额外的DAL层，它最终是一个外观。。

---

我看到的唯一优势是，我们必须更改数据访问实现，比如用Hibernate或其他方法替换EF。但老实说，我从未见过这种情况发生。

事实上，对于数据映射器来说，开发DAL的必要性毫无用处，因为它将包含0行代码

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

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

---

最后，即使实体框架实现了工作单元和其他模式，有时它们的实现也可能不适合您自己的领域需求，您需要对它们进行包装，以便为您的领域提供更多的具体化。

同意mock，但我认为转换基础数据仍然不常见，也没有理由额外花费20%time@BobyOneKenobi今天多点时间，明天少点时间；）@bobyonekenobi顺便说一句，如果你知道如何用DDD的方式编写代码，你不需要20个℅ 额外的时间。如果这是您第一次实现DDD，可能会出现时间损失，因为存在一条学习曲线……“直接在业务层调用EF”-具体在哪里？在业务对象本身中？作为运行业务用例的服务/事务脚本的一部分？在位于业务层的独立存储库类对象中？@guillaume31，不是业务对象本身，而是来自服务。例如：公共OrderService（IORDrepository repo）{this.repo=repo}public void Save（OrderDTO order）{var OrderEntity=convertdotoEntity（order）；if（OrderEntity.CheckBusinessRules（））repo.Save（OrderEntity）}