我一直使用直接数据访问来处理过去的对象（手动运行查询，并将结果映射到数据对象）。我知道微软目前正在推动EF让客户用来查询数据对象。
我对社区提出了一些问题： -
如果你有一个复杂的数据库，即几百个表，相当数量的存储过程，视图，一切都在3NF。管理两个模式（一个本地EF模式映射和一个数据库）的负担值得权衡吗？
一旦开始加速数据访问，缓存如何在两者上进行比较？我知道在直接访问中你可以实现你想要的任何形式的缓存，EF是否允许类似的东西？
考虑到微软在大力推动产品并让人们为他们写作（SQL-NS，Linq-to-Sql）之后杀掉产品的历史，这对EF来说有多大的影响？
正如我所说，我目前正在大量使用直接访问，但考虑到迁移（即未来的新查询，还没有回溯它们），并且正在寻求社区其他人的建议对他们的看法。
答案 0 :(得分：4)
如果你有一个复杂的数据库，即几百个表，a 相当数量的存储过程，视图，一切都在3NF。是 管理两个模式的负担（一个本地EF模式映射和 一个DB）值得折衷吗？
您可以使用自动化工具使您的EF架构保持最新状态，因此它并不是那么糟糕。
一旦开始加速数据访问，缓存如何比较 他们俩？我知道在直接访问中，您可以实现任何形式的缓存 你想要，EF是否允许类似的东西？
据我所知，是的。
考虑到微软历史上大量淘汰产品的历史 推动他们并让人们为他们写作（SQL-NS， Linq-to-Sql）这怎么会发生在EF？
这个问题太过假设了。
我与EF有关的问题是它的表现。是的，你得到了快速的发展，但是在性能上有所作为。使用EF，编写错误和慢速的代码非常容易，如果您不能100％知道自己正在做什么，那么以后可能会遇到一些严重的性能问题（特别是如果您和＃39;处理数百个表格。
我建议尝试一些微型ORM框架，如Dapper或Massive。你不会牺牲那么多的表现，但它比传统的Ado.net方法更容易维护。
但是，嘿，那只是我，你可能喜欢EF。
答案 1 :(得分：1)
使用EF或任何其他ORM工具时要记住的是，它只是将某些内容（在EF和Linq2Entities的情况下为Linq表达式树）转换为SQL语句。由于那里有一个额外的抽象层和解析层，所以直接查询总是会慢一些。但是，开发人员通常更容易使用ORM。幸运的是，大多数ORM（特别是对EF不确定）提供了一些在需要时直接运行查询的方法。
你提到有一个“复杂”的数据库，这通常意味着有复杂的查询。这是Linq不太喜欢的东西。例如，如果你最终得到连接13个表的查询，并且几乎每个返回的列都被传递给db函数，并且有一堆case语句和一堆子选择，那么它几乎不可能转换为Linq 。更容易做的是在视图中包含该复杂性，并使用EF来查询视图。
从好的方面来说，EF为开发人员提供了智能感知，因为真正的类是为了模仿数据库而构建的。根据您的EF内容的布局方式，您可以设置项目，使得所有类都是从DB生成的，因此如果有人编辑数据库模式或更改列数据类型，您的C＃代码将不再编译。使用传统的直接SQL查询，您永远不会在运行时（或集成测试时间）之前找到它。
这是所有的权衡... IMO最好的办法是尝试两者，看看你更喜欢哪一个，或者以提供任一选项的方式构建解决方案。在我工作的最后一个应用程序中，我有一个“数据库工厂”类（工厂模式），其他数据访问类将使用它们，他们可以要求工厂提供一个普通的旧ADO.NET Command对象，或者要求ORM对象（EF情况下的Context，但我使用的是SubSonic，因此它是一个IQueryable实现）。这样，您可以通过EF执行“简单”查询，并在SQL中执行“复杂”查询。
答案 2 :(得分：1)
与直接数据访问相比，EF的主要优势在于开发人员的工作效率。
很少有开发人员编写汇编代码，我们让编译器生成它。随着像EF这样的工具变得更好，我们将更多地使用它们并停止编写SQL。
但是，有时您需要额外的控件来获得所需的性能，因此您仍可能需要编写一些SQL代码。就像仍然有一些汇编代码一样。
转换有效的解决方案没有商业价值。您可以尝试使用EF进行新开发。