您认为切换到实体框架是否有利?

时间:2008-11-09 20:25:44

标签: .net linq-to-sql entity-framework ado.net

使用LINQ to SQL很可能无法获得与实体框架一样多的活动开发,您认为最好切换到实体框架吗?

我个人认为,与LINQ to SQL相比,EF非常笨重且难以使用,感觉非常自然。

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

ADO.NET v LINQ to SQL

8 个答案:

答案 0 :(得分:22)

IMO,暂时不是。

很明显(特别是来自recent announcements)EF因为“thunderdome”场景在LINQ-to-SQL和EF之间播放而进行了大量修改。无论发生什么,EF(在几年内)几乎肯定会与EF今天看起来完全不同。或者当然“足够不同”;-p

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

如果我知道它会很快发生变化,我认为学习一个臭名昭着的复杂系统并没有多大好处。

我在LINQ-to-SQL上与你100%合作;-p

如果我现在需要的不仅仅是LINQ-to-SQL,我会查看NHibernateLLBLGen Pro

编辑 - 作为更新,我的位置有点软化,herehere - 但我仍然使用LINQ-to-SQL作为我的主要工具;还有 - LINQ-to-SQL isn't quite dead yet ;-p)。

答案 1 :(得分:7)

我已经完成了一些MVC项目,现在正在使用L2SQL进行生产,并且发现使用起来非常愉快。我现在正着手一个新项目并决定使用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没有的少数事情,例如Single()和SingleOrDefault(),可以通过创建一些扩展方法迁移到EF。我认为使用L2SQL使系统运行所需的时间要少得多,然后在EF不那么臭的情况下将其移植到以后。

答案 2 :(得分:6)

如果您正在进行数据库驱动的开发,那么EF今天具有真正的优势。

我已经使用了LINQ to SQL和EF,并解决了EF v1的许多小挫折。

但是,使EF v1获胜的一件事就是从数据库向导中获得了非常好的更新。令人难以置信的是,这个实际上是有效的!这可能听起来微不足道,但是如果您正在进行数据库优先设计,那么您希望依靠工具为您创建类,并且您不希望仅为了进行更改而重新生成整个模型。

仅此一点就是我选择EF v1。我建议忽略EF v1的高级功能 - 它远没有用作它目标的雄心勃勃的平台。

忍受EF v1的笨拙,你将处于未来的最佳状态。

皮特。

答案 3 :(得分:3)

我必须同意Marc Gravell。 可能当下一版本的Entity Framework发布(.net 4.0 / VS2010)时,使用EF会有一个优势,那么它可能与当前版本的EF非常不同。< / p>

在那之前,除了测试/实验代码之外,至少我会避免像瘟疫这样的瘟疫。

EF msdn forum充满了关于为什么EF还没有为黄金时间做好准备的例子,但我有one particular example这是一个明显的赢家 - 通常是一个简单的五表查询(当使用EF和EntityDataSource控件时,10-15行SQL)变为>1500 lines of SQL

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

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

至于EF的未来 - 微软的history of changing direction在一夜之间对大战略事件有所了解,谁知道他们目前与EF的“战略目标”是否会在几年之后实现......?我肯定不会赌它。参见:

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

答案 4 :(得分:2)

为了记录,有关LINQ to SQL未来的一些犹豫在这里表达了:

Is LINQ to SQL DOA?

Has Microsoft really killed LINQ to SQL?

答案 5 :(得分:2)

LINQ to SQL似乎不是一个选项,除非你使用SQL Server(或SQL Server compact),所以这足以让我避免它并使用EF(我想使用PostgreSQL)。

在EF的v1中肯定有足够的东西会让我犹豫推荐它。听起来像EF版本2(发布时)将是第一个可以认真推荐切换到的版本。

答案 6 :(得分:1)

相当多的有经验的开发者提供了“ADO .NET Entity Framework Vote of No Confidence”,正如进一步讨论here

我认为我们期望ADO.Net团队在.Net 4.0中对其进行大幅改进。

这是最近PDC的一些video

答案 7 :(得分:-1)

最近,我不得不研究哪个ORM项目应该使用。起初 - 试过L2S。它一点也不差,但它已经过时了(MS不再支持它了),这就是我开始查看L2E的原因。我对生成的代码很好,但是在它们之间创建虚假的视图,实体和映射只是为了使存储过程可用而不是填充实体的所有字段对我来说太过分了。我想分离我的dataaccess层,所以 - 我必须将生成的对象中的数据映射到我制作的对象。

用了几个小时的NHibernate + Fluent NHibernate + LINQ到NHibernate实验 坚持这种组合。