过去，我一直使用直接数据访问来处理对象(手动运行查询，并将结果映射到数据对象)。我知道 Microsoft 目前正在插入 EF 供其客户用于查询数据对象。
我有几个问题要问社区:-
如果您有一个复杂的数据库，即几百个表、相当数量的存储过程、 View ，一切都在 3NF 中。管理两个模式(一个本地 EF 模式映射和一个数据库)的负担是否值得权衡？
一旦开始增加数据访问，两者的缓存比较如何？我知道在直接访问中你可以实现你想要的任何形式的缓存，EF 是否允许类似的东西？
鉴于 Microsoft 在大力插入产品并让人们为它们编写代码(SQL-NS、Linq-to-Sql)后淘汰产品的历史，这怎么可能发生在 EF 上？
正如我所说，我目前正在大量使用直接访问，但正在考虑迁移(即继续进行新查询，而不是对它们进行回溯)，并且正在寻求社区其他人的建议对他们的看法。
最佳答案
If you have a complex database, i.e. a couple of hundred tables, a decent amount of stored procedures, views, everything is in 3NF. Is the burden of managing two schemas (one local EF schema mapping and one DB) worth the trade off?
您可以使用自动化工具来使您的 EF 架构保持最新，所以它并没有那么糟糕。
Once you start to ramp up the data access, how does caching compare on the two? I know in Direct access you can implement any form of caching you want, does EF allow something similar?
据我所知，是的。
Given Microsoft's history of killing off products after heavily pushing them and getting people to write for them (SQL-NS, Linq-to-Sql) how likley is this to happen to EF?
这个问题太假设了。
我在使用 EF 时遇到的问题是它的性能。是的，你得到了快速发展，但牺牲了性能。使用 EF 很容易编写糟糕且缓慢的代码，如果您不是 100% 知道自己在做什么，以后可能会遇到一些严重的性能问题(尤其是当您处理数百个表时) .
我的建议是尝试一些 Micro-ORM 框架，例如 Dapper 或 Massive。您不会牺牲那么多性能，但它比传统的 Ado.net 方法更容易维护。
但是嘿，这就是我，您可能会喜欢 EF。
关于c# - Entity Framework 与直接数据访问，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11071149/