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

Question

在任何情况下，EF都不是理想的数据访问解决方案吗？我想回到DataReader和DataSet之间的对比，以及在尝试流式传输大量数据时，后者通常是不可取的。所以我很好奇是否存在EF不是一个好主意的用例。或者也许是替代EF提出挑战或者如何使用它？感谢

Answer 1

一般来说，所有的abstration都会呈现出某种东西。外观的原因可能有很多原因，但通常它们简化了复杂性。

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

所以答案是 - EF提供的功能不会克服受其操作方式限制的好处和努力。

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

Answer 2

在每一个非平凡的现实世界中，如果你更关心用户满意度，那么就是简单和程序员方便的空洞承诺。如果您更关心完成任务，那么调试漏洞抽象。