实体框架与直接数据访问

Question

我总是使用直接数据访问来处理过去的对象(手动运行查询,并将结果映射到数据对象).我知道微软目前正在推动EF让客户用来查询数据对象.

对于社区,我有几个问题: -

• 如果你有一个复杂的数据库,即几百个表,相当数量的存储过程,视图,一切都在3NF.管理两个模式(一个本地EF模式映射和一个数据库)的负担值得权衡吗？

• 一旦开始加速数据访问,缓存如何在两者上进行比较？我知道在直接访问中你可以实现你想要的任何形式的缓存,EF是否允许类似的东西？

• 考虑到微软在大力推销产品并让人们为他们写信之后杀掉产品的历史(SQL-NS,Linq-to-Sql),这对EF来说有多大可能？

正如我所说,我目前正在大量使用直接访问,但考虑到迁移(即新的查询未来,还没有回溯它们),并且正在寻求社群其他人对他们观点的建议.

Answer 1

如果您有一个复杂的数据库，即数百个表、大量的存储过程、视图，那么一切都在 3NF 中。管理两个架构（一个本地 EF 架构映射和一个数据库）的负担值得权衡吗？

您可以使用自动化工具来使您的 EF 架构保持最新，因此这并没有那么糟糕。

一旦开始增加数据访问，两者的缓存比较如何？我知道在直接访问中你可以实现任何你想要的缓存形式，EF 是否允许类似的东西？

据我所知，是的。

考虑到微软在强力推动产品并让人们为它们编写（SQL-NS、Linq-to-Sql）之后淘汰产品的历史，这种情况发生在 EF 上的可能性有多大？

这个问题太假设了。

我对 EF 遇到的问题是它的性能。是的，您可以获得快速发展，但会牺牲性能。使用 EF，很容易编写出糟糕且缓慢的代码，如果您不能 100% 知道自己在做什么，稍后可能会遇到一些严重的性能问题（尤其是在处理数百个表时） 。

我建议尝试一些 Micro-ORM 框架，例如 Dapper 或 Massive。您不会牺牲太多性能，但它比传统的 Ado.net 方法更容易维护。

但是嘿，这只是我的看法，你可能会喜欢 EF。