考虑到 LINQ to SQL 可能不会像 Entity Framework 那样得到很多活跃的开发,您认为最好切换到 Entity Framework 吗?
就我个人而言,相比于LINQ to SQL,我发现EF非常笨拙且难以使用,而LINQ to SQL则感觉非常自然。
编辑:我最近在我的博客上发布了一篇关于这个潜在决定的文章...
考虑到 LINQ to SQL 可能不会像 Entity Framework 那样得到很多活跃的开发,您认为最好切换到 Entity Framework 吗?
就我个人而言,相比于LINQ to SQL,我发现EF非常笨拙且难以使用,而LINQ to SQL则感觉非常自然。
编辑:我最近在我的博客上发布了一篇关于这个潜在决定的文章...
在我看来,目前不需要。
从最近的公告(尤其是这里)可以清楚地看出,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)。
我已经完成了几个使用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不那么臭的时候再进行移植。
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
许多有经验的开发人员已经给出了 "ADO .NET实体框架不受信任的投票",更多讨论请参见此处。
我认为我们期望ADO.Net团队在.Net 4.0中对其进行显着改进。
这里还有一些来自最近PDC的视频。