10

我听说实体框架是矫枉过正，或者与 LinqToSql 相比，它很难学习。

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

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

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

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

我首先从单个表中删除 1000 条记录，添加 1000 条记录，编辑 1000 条记录，然后将它们数据绑定到 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 复杂。

4

6 回答 6

12

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

于 2008-11-07T16:00:42.983 回答
8

Linq to SQL 和实体框架在概念上是不同的野兽，您应该根据它们如何满足您的需求而不是微基准来做出选择。即使Entity Framework速度较慢，但​​它是微软ADO.NET团队的重点，并将多次改进。Linq-to-SQL 被有效地冻结。

从概念上讲，它们的不同之处在于 Linq-to-SQL 只是一种使用 Linq 执行数据库查询的方式。听起来很明显，但重点是：您正在访问根据其数据库模型结构化的数据。尽管 FK 被适当地转换，但您仍然有多余的对象，其中数据被规范化到不同的表中。您编写的每个查询都必须处理这种事情。

Entity Framework 允许您以声明方式构建一个层，该层以应在内存中表示的方式表示您的数据，将来自多个表的数据带到适当的单个对象中；将多对多关系表示为集合属性等。然后您编写的查询将针对此模型，并且目的更清晰，更明显（不再有 15 个表连接！）。

如果您不确定是否使用 Entity Framework，O'Reilly 将在 2009 年 1 月 15 日出版 Entity Framework 的综合性书籍（预览版现已在 Roughcuts 上提供） - 它的 MSDN 文档目前非常糟糕，这使得提出它变得更加困难. 我确实相信它值得长期使用，除了最微不足道的项目（而且就个人而言，如果我写一些微不足道的东西，我会直接使用 ADO.NET2 并忘记 Linq）。

于 2008-12-30T00:33:42.553 回答
5

不过要小心，如果您使用带有分组依据的查询，LinqToEntities 可以做一些非常有趣的事情。我从来没有设法让 LinqToEntities 将 group by 转换为实际的 SQL group by，而是生成一些非常无效的大量代码块。

例如，查看以下链接： http ://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85-31d0b6a85f68

如果您尝试编写“非平凡的”查询，ObjectQuery.ToTraceString() 是您最好的朋友，以确保 EF 不会在您背后做一些非常愚蠢的事情。

于 2010-02-16T10:16:15.973 回答
3

我的回答：对执行简单的获取/编辑/更新序列所花费的时间进行简单的比较。我想你会发现 LINQ to SQL 的速度是原来的两倍。在调查差异时，我做了一个快速比较项目。
结果： 实体框架 8,700 毫秒 LINQ to SQL 3,100 毫秒 数据集 2,000 毫秒

所以对我来说这是一个简单的问题。使用 DataSets 或使用 Linq-Sql - 实体框架甚至没有考虑到它！

链接文本

于 2008-11-06T01:17:32.733 回答
3

在深入了解 Linq To SQL 之前，请查看其项目经理的这篇文章。他提出了一个直截了当的问题“LINQ to SQL 死了吗？” 答案并不那么简单。这绝对不是“不”。在我看来更像是“可能”。

我建议您在深入研究 EF（现在称为 Linq To Entities）之前认真考虑 NHibernate，但这是我个人的偏见。

于 2008-11-07T16:16:39.783 回答
2

为什么不用SqlDataReader 做一个普通的SQL 查询并将它们绑定到一个通用列表。似乎 SQL 比任何 ORM 都更加灵活和强大。反正在实践中！！SQL死了吗？这一定是最快的方法，缺点是 sql 字符串，但你工作得更接近金属，感觉比使用任何 ORM 有更多的控制权。感觉像 ORM:s 总是有一些错误，并且使更复杂的查询变得很痛苦，并且比你应该用纯 SQL 完成它们需要更长的时间来编写它们。还是只有我对 ORM:s 不熟悉？

于 2010-08-09T18:46:07.133 回答