Linq2SQL与.net Framework 4.0中的EF

Question

那么现在对这两种产品的判断是什么呢？对于VS2010/.net 4.0,我似乎无法找到关于此问题的任何内容

回到.net 3.5天,大多数人认为当.net 4.0出现时,Linq2SQL将会死机,但它看起来还活着.

另一方面,EF 4.0似乎已经有了显着的改进.

对我来说,到目前为止,我的大部分工作都是中小型项目,我的公司很快就会从VS08迁移到VS10.我应该看什么？或者真的,我应该花时间研究EF4.0还是花时间更好地研究nHibernate？(但回到主题,我对Linq2Sql - EF真的更感兴趣.)

最后,我目前正在使用entlib/unity,哪个框架对依赖/策略注入更友好？

提前致谢.

Answer 1

以下是实体框架(v4)更好的一些原因:

1 - L2SQL基本上已经过时了

2 - L2SQL不支持POCO映射,EF确实如此.

3 - EF具有更大的灵活性(代码优先,模型优先,数据库优先).L2SQL只有1个.

4 - EF支持SPROC - > POCO映射

5 - EF具有Entity-SQL,允许您在需要时返回到经典的ADO.NET

6 - EF支持继承(TPT,TPH)

7 - EF与Repository模式密切相关,并通过IQueryable延迟执行

8 - EF组件(ObjectSet,ObjectContext)很容易模拟并允许DI

我想不出为什么新项目应该使用L2SQL.

有些人可能会说"L2SQL对小型项目有好处,我可以拖放它并完成它".

那么你也可以用EF4做到这一点,如果你决定修改/扩展你的项目,你将在长期内获得更多的灵活性/支持.所以这不是借口.

HTH

Answer 2

只是为了添加以前的答案和评论(这三个人都获得了+1票):

a)性能:L2S运行时比EF更轻量级(由于只有一个层; EF必须处理两个模型层以及它们之间的映射).

EF通常会生成比L2S更冗长的TSQL,但大多数时候只会影响可读性,如果您正在分析并查看生成的查询; SQL优化器大多数时候都会以相同的执行计划结束.但是,在某些情况下,查询会变得如此庞大和复杂,以至于可能会对性能产生影响.

L2S在进行客户端查询优化方面也略胜一筹; 它消除了可以在客户端评估的where子句谓词,因此数据库不必担心它们.这意味着SQL Server优化器的工作量减少,并且您最终会遇到"糟糕"的执行计划的风险降低.

b)L2S与L2E:在将使用普通CLR方法的LINQ查询转换为TSQL时,L2S仍然略好于L2E,特别是在涉及DateTime和与之相关的方法时.L2E支持或多或少相同的东西,但通过它自己的EntityFunctions类:http://msdn.microsoft.com/en-us/library/system.data.objects.entityfunctions.aspx.

在我看来,L2S和EF都是很好的选择,选择一个你觉得舒服的东西,并涵盖你现在需要的东西以及你正在编写的代码的合理生命周期.在你知道之前,微软可能会宣布另一种数据访问技术.他们似乎每3 - 5年就这样做... :) DAO,RDO,ODBC,ADO,OLEDB,ADO.NET,类型化数据集,ObjectSpaces,WinFS,L2S,EF,等等.我写的代码15几年前,针对DAO的应用仍在市场上,尽管DAO已经"死"了多年,但仍然有效.

有时名称会被重新用于全新的数据访问技术,但这并没有改变这样一个事实,即微软最新的数据库访问技术构成了一个不断变化的目标......