你认为转换到Entity Framework是否有优势?

25

考虑到 LINQ to SQL 可能不会像 Entity Framework 那样得到很多活跃的开发,您认为最好切换到 Entity Framework 吗?

就我个人而言,相比于LINQ to SQL,我发现EF非常笨拙且难以使用,而LINQ to SQL则感觉非常自然。

编辑:我最近在我的博客上发布了一篇关于这个潜在决定的文章...

ADO.NET v LINQ to SQL

8个回答

22

在我看来,目前不需要。

从最近的公告(尤其是这里)可以清楚地看出,EF将会经历一些重大改进,因为“thunderdome”情况正在LINQ-to-SQL和EF之间发生。无论发生什么事情,EF(在未来几年内)几乎肯定会与今天的EF看起来完全不同。或者至少“足够不同”;-p

因此,我的观点是:坚持简单,而简单就是LINQ-to-SQL。

如果我知道它很快就会改变,我不认为学习一个臭名昭著的复杂系统有多大好处。

我100%支持你的LINQ-to-SQL;-p

如果我现在需要比LINQ-to-SQL更多的内容,我会考虑NHibernate,或者可能是LLBLGen Pro

编辑 - 作为更新,我的立场已经有所软化,在这里这里 - 但我仍然把LINQ-to-SQL作为我的主要工具;此外 - LINQ-to-SQL并没有完全死亡;-p)。


1
太对了!我喜欢L2S,但是我有点讨厌EF :)(因为有实际的、具体的原因)。 - Timothy Khouri
@Timothy - 是的,有原因。像 Ian Cooper 这样的人可以整天谈论它们 ;-p(好家伙,懂他的 ORM 东西) - Marc Gravell
同意,非常准确!当 EF vNext 和 .net 4.0 发布后,应该再仔细研究一下。在那之前,使用 L2S... - KristoferA
不幸的是,微软有一个习惯,即无论技术价值如何,都会将数据访问策略推进到90%,然后每隔几年重新发明一种新的数据访问策略。 - Robert Paulson
1
“Simple is LINQ-to-SQL (Server)”…那么它在其他数据库引擎上的表现如何呢?不太好,是吧? - Jason Short
@J 简而言之,为了让这个问题有意义,必须先假定使用 SQL Server。请注意,还有其他提供商(第三方)的 DbLinq。 - Marc Gravell

7

我已经完成了几个使用L2SQL的MVC项目并在生产中运行,发现使用起来非常愉快。现在我正在开始一个新项目,并决定使用EF和L2EF来编写它,鉴于之前引用的文章宣称L2SQL已经死亡。但只过了几天,我决定回到L2SQL。诸如必须使用下面显示的可怕语法或不必要的查找来设置插入的外键等简单事情让我感到震惊。

foo.Foreign_TypeReference.EntityKey = 
     new EntityKey("DataContextName.Foreign_Type", "Foreign_Type_Id", ForeignTypeId);

改为:

foo.Foreign_Type_Id = ForeignTypeId;

我认为将L2SQL移植到未来的EF版本并不会很困难,因为L2SQL具有功能子集(尽管实现得更好)。 L2SQL拥有的一些L2EF没有的功能,例如Single()和SingleOrDefault(),可以通过创建一些扩展方法来迁移到EF。 我认为使用L2SQL来让系统运行起来需要的时间要少得多,然后在EF不那么臭的时候再进行移植。


这基本上就是我的想法。我希望EF vNext会更漂亮。 - Marc Gravell

6
如果你正在进行基于数据库的开发,EF在今天有真正的优势。
我使用过LINQ to SQL和EF,并且经历了EF v1的许多小挫折。
然而,使EF v1对我胜利的一件事是惊人的“从数据库更新”向导。难以置信的是,这个功能实际上是有效的!这听起来可能微不足道,但如果你正在进行数据库优先设计,你想要依靠工具为你创建类,而不想不得不重新生成整个模型来进行更改。
仅此一点就使EF v1成为我的选择。我建议忽略EF v1的高级特性 - 它还远远不能作为它旨在成为的雄心勃勃的平台使用。
忍受EF v1的笨拙,您将处于未来的最佳位置。
Pete.

4
“好的”“从数据库向导更新”?它不会检测现有列中的空值、数据类型等更改吗?如果有更新,它会替换整个EDMX文件中的SSDL部分,并覆盖您可能对其进行的任何自定义修改。 - KristoferA
3
那个不能重新添加已删除实体的问题,如果你不使用XML编辑器手动清除SSDL工件,就无法解决?噢好吧,他们说这在Visual Studio 2010中会更好。与此同时,我将坚持使用L2S,并使用我的同步工具为L2S模型更新仅适用更改。 - KristoferA

3
我必须同意Marc Gravell。也许等到下一个版本的Entity Framework发布(.net 4.0 / VS2010),使用EF会有优势,那时它可能与当前版本的EF非常不同。
在那之前,至少除了测试/实验代码,我会像瘟疫一样避开EF,因为它还没有准备好投入生产。 EF msdn论坛充满了示例,说明EF还没有准备好用于主流应用,但有一个特别的例子是明显的胜者-当使用EF和EntityDataSource控件时,通常只需要五个表的查询(10-15行SQL)变成了>1500行SQL

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3874607&SiteID=1

http://paste-it.net/public/q6ed5c2/

至于EF的未来 - 鉴于微软在大型战略问题上随时改变方向的历史,谁知道他们当前关于EF的“战略目标”几年后是否会实现呢?我肯定不会打赌。参见:history of changing direction

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=4100399&SiteID=1#4107623


那个有1,500行的查询太荒谬了,我简直不敢相信。 - Chad Moran
是的,那些巨型查询确实令人惊讶。这里有另一个有趣的例子;在两个表上进行分组+聚合的简单查询。L2S生成了一个高效的查询,而L2E则没有。 http://social.msdn.microsoft.com/Forums/en-US/adodotnetentityframework/thread/bb72fae4-0709-48f2-8f85-31d0b6a85f68 - KristoferA

2
LINQ to SQL 似乎不是一个选项,除非您使用 SQL Server(或 SQL Server compact),所以这已经足够让我避免使用它并使用 EF(我想使用 PostgreSQL)。
EF 的第一版中确实缺少了足够多的东西,这使得我在推荐时会犹豫。听起来 EF 的第二版(发布后)将是第一个可以认真考虑切换的版本。

准确无误 - l2s 仅支持 SQL Server。EF = 其他提供者。 - Jason Short

2

但我的关键点是:在如此多的变化中,大量投资是一个错误。LINQ-to-SQL 需要非常少的投资,所以我不认为这是一个很大的风险。 - Marc Gravell
我完全同意,Marc。我只是想指出对于那些可能不知道(就像我最近在SO上读到的那样),LINQ to SQL并非没有风险。当然,风险很低,而且短期内肯定有很高的收益。从SO的问题数量可以看出它非常受欢迎。 - DOK
确实。一定要喜欢这个策略:杀死人们真正喜欢的实现 ;-p 公平地说,情况比那复杂得多,我期待几年后(.NET 4.0)的“真正”答案。微软在这里有一个公关/开发信心的难题要克服。我希望他们能成功... - Marc Gravell
因为 LINQ 真的是我见过的最具有开创性、令人印象深刻和雄心勃勃的概念之一。如果它因两个竞争性实现之间的斗争而被破坏,那将是一件非常遗憾的事情。 - Marc Gravell
兄弟,阿门。的确是雷鸣般的竞技场。 - DOK

1

-1
最近,我不得不研究应该使用哪个ORM项目。起初,我尝试了L2S。它并不差,但它已经过时了(微软不再支持它),这就是为什么我开始查看L2E的原因。我对生成的代码很满意,但是创建虚假视图、实体和它们之间的映射只是为了使存储过程可用而不填充实体的所有字段对我来说有些过度。而且我想要分离我的数据访问层,所以我必须将数据从生成的对象映射到我自己制作的对象。
我花了几个小时尝试NHibernate+Fluent NHibernate+LINQ to NHibernate的组合才坚持下来。

2
这是不正确的。微软目前有5个开发人员在LINQ to SQL上工作。 - Chad Moran
啊哈...昨天看到他们正在修复漏洞。是我的错误。不管怎样,这并不改变我的观点。 - Arnis Lapsa
.NET 4.0会对LINQ To SQL进行一系列的改进http://damieng.com/blog/2009/06/01/linq-to-sql-changes-in-net-40 - Paul Mendoza
@Paul,我在那篇博客文章之前写了这个答案。 - Arnis Lapsa

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接