相关疑难解决方法(0)

现在已经发布了.NET v3.5 SP1(以及VS2008 SP1),现在我们可以访问.NET实体框架了.

我的问题是这个.在尝试使用Entity Framework和LINQ to SQL作为ORM时,有什么区别？

我理解它的方式,实体框架(当与LINQ to Entities一起使用时)是LINQ to SQL的"大哥"？如果是这种情况 - 它有什么优势？它能做什么LINQ to SQL本身无法做到的？

• LINQ(语言集成查询)的优缺点是什么？
• 使用LINQ的最佳和最差情况是什么？
• 您如何从使用LINQ中受益或不受益？
• LINQ中哪些数据源受益最少和最多？

如果开始一个新项目,你会为ORM NHibernate或LINQ使用什么,以及为什么.每种方法的优缺点是什么？

编辑:LINQ to SQL不仅仅是LINQ(感谢@Jon Limjap)

我听说它说实体框架太过分了,或者与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 Entities与Linq对SQL并不是真的有点过分.在研究了更多之后,我认为与Linq一起实现实体是可行的方法.它似乎有更好的表现.

我相信我所听到的"矫枉过正"声明是因为Linq to Entities可以做的远不止Linq To SQL,它确实需要更多配置(在web.config中大约多一行).Linq to Entities也有一些小事情,从Linq到SQL可能会让人觉得Linq to Entities更复杂.但是一旦你学会了如何做事,看起来Linq to Entities并不比Linq to SQL复杂.