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

使用LINQ to SQL很可能不会像实体框架那样获得尽可能多的活动开发,您认为最好切换到实体框架吗？

我个人发现EF非常笨重而且难以使用,而LINQ to SQL感觉非常自然.

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

ADO.NET v LINQ to SQL

1> Marc Gravell..：

---

国际海事组织,现在不是.

很明显(特别是最近的公告),由于" thunderdome "场景在LINQ-to-SQL和EF之间发挥作用,EF 正在进行一些重大修订.无论发生什么,EF(在几年内)几乎肯定会与EF今天看起来完全不同.或者当然"足够不同";-p

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

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

在LINQ-to-SQL上,我100%和你在一起;-p

如果我现在需要的不仅仅是LINQ-to-SQL,我会看看NHibernate或者LLBLGen Pro.

(编辑 - 作为一个更新,我的位置已经软化了一点,这里和这里 - 但我仍然使用LINQ-to-SQL作为我的主要工具;而且 - LINQ-to-SQL 还没有完全死亡 ; - p).

2> LaserJesus..：

---

我已经完成了一些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不那么臭时将其移植到以后.

3> Pete Montgom..：

---

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

我已经使用了LINQ to SQL和EF,并完成了EF v1的许多小挫折.

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

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

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

皮特.

---

数据库向导的"好"更新'?? 如果您在现有列上更改了可空性,数据类型等,则无法检测到的那个？在更新某些内容时替换EDMX的整个SSDL部分,覆盖您可能对其进行的任何自定义？

---

(续)如果不使用xml编辑器手动清除SSDL工件,则无法重新添加已删除实体的实体？哦,他们说在Visual Studio 2010中它会更好.同时我坚持使用L2S并使用我的同步工具更新我的模型,用于仅应用更改*的L2S模型*.