.net - .net Entity Framework 与 LinqToSql 相比如何？

Question

我听说 Entity Framework 是矫枉过正，或者与 LinqToSql 相比，它很难学习。

我想知道以什么方式？我使用了 LinqToSql 并喜欢它。所以，我正在尝试 EF，而对于我正在做的事情，它们看起来几乎完全相同。命名空间和方法名称不同，但到目前为止，我没有看到任何使 EF 比 LinqToSql 更难的东西。

我敢肯定，如果我开始做更复杂的事情，它会变得更复杂。但话又说回来，我可能根本无法用 LinqToSql 做同样的事情，所以我认为这是 EF 的一个加分项，以防万一我确实想做更复杂的事情。

EF 是否使用了比 LinqToSql 更多的资源，以至于如果我只需要类似 LinqToSql 的功能，我就不应该使用它？

更新:
我做了一些测试，我的测试似乎表明 Linq to Entities 的性能优于 Linq to SQL。

我首先从单个表中删除 1000 条记录，添加 1000 条记录，编辑 1000 条记录，然后将它们数据绑定(bind)到 DataView。 LinqToSQL:5 秒 LinqToEntities:2 秒

我使用两个连接表执行了相同的测试，结果相似。

我的测试似乎支持另一篇文章:
Linq To Sql vs Entity Framework Performance

更新 2:

感谢您的回复。在我看来，与 Linq to SQL 相比，Linq to Entities 并没有真正矫枉过正。在研究了更多之后，我认为使用 Linq to Entity 是要走的路。它似乎有更好的性能。

我相信我听到的“矫枉过正”的说法是因为 Linq to Entities 可以比 Linq To SQL 做更多的事情，而且它确实需要更多的配置(web.config 中大约多 1 行)。此外，Linq to Entities 所做的一些小事情与 Linq to SQL 不同，这可能会让人们觉得 Linq to Entities 更复杂。但是一旦你学会了如何做事，Linq to Entities 似乎并不比 Linq to SQL 复杂。

Answer 1

如果我错了，请纠正我，但 Entity Framework 应该只在您需要转换后端对象时发挥作用，例如当您组合来自不同数据源的表、拆分表等时。它添加了实体层所以你可以隐藏所有的管道，只处理你清理过的实体。如果您只是像在 LINQ to SQL 中那样对您的表使用 1 对 1，那么我确信您不使用的那层复杂性会减慢它的速度。听起来 LINQ to SQL 是适合您的工作的正确工具，直到您有更复杂的数据源需求。