.net - 不应使用实体框架的情况？

Question

是否存在 EF 不是数据访问的理想解决方案的情况？我回想起 DataReader 和 DataSet 之间的对比，以及后者在尝试流式传输大量数据时通常是不可取的。所以我很好奇是否存在 EF 不是一个好主意的用例。或者，也许 EF 在其使用方式上提出了挑战或陷阱？谢谢

Answer 1

一般来说，所有抽象所做的只是呈现某物的外观。外观的原因可能有很多原因，尽管通常它们呈现出复杂性的简化。

EF 提供了 ORM 分层，以减少从面向对象世界映射到关系世界的复杂性所带来的阻抗。这样做的开销与滚动您自己的映射不同。在某些方面它更容易，而在其他方面它更难。提供功能的一部分是增加开销（无论是性能还是问题域的有效性），这需要进行管理。此外，简化某些事情的抽象（根据我的经验）通常会限制您可以做什么或不可以做什么。在任何设计中也需要考虑这一点。

所以答案是 - EF 提供的功能并没有克服受其做事方式限制的好处和努力。

一个经典的例子，如果这是简单的 CRUD 客户端服务器应用程序，现在通常可以使用 Codesmith 或 IronSpeed 或类似工具自动生成。

Answer 2

在几乎每一个重要的现实世界情况下，如果您更关心用户满意度，那么就只是对简单性和程序员便利性的空洞承诺。如果您更关心完成工作，那么调试泄漏的抽象。