修改
欣赏所有输入人员。意见非常受欢迎，我认为我们将在这一点上采用L2S实现，只是以这样的方式汇总/封装我们的DAL，如果我们将来需要更改为EF，它将不会太无痛一项行动。
由于这是非常主观的，所以积分会转到最热门的海报上。
ORIG
我一直在努力跟上整个实体框架的速度。 Linq2SQL主题 例如，已经有一些问题了。
Entity Framework Vs. Linq To Sql
我想知道的是（欢迎提出意见）如果你开始一个新的重大项目，你会使用Linq2SQL作为你的数据访问层。
为了给出一些上下文，我们是.NET C＃House，DB是SQL Server 2000，但我们可能会在今年晚些时候将其移植到SQL 2005。在我们的小型开发团队中，我是唯一一个拥有C＃3.0 / .NET 3.5经验的人。团队中的其他人在过去的3年中一直使用手工剪切ADO.NET＆amp;数据访问层的SqlHelper代码。
我想，我的主要担心是我们将开始使用更高级/可用/更快速开发的新项目（即L2S），但最终它已经过时了。
我们是否应该接受命中，延迟项目并调查使用VS2008中的实体框架。
为任何输入人员干杯。
答案 0 :(得分：5)
虽然微软继续支持Linq，但我怀疑它很有可能被实体框架打败，但他们不想引起恐慌，并且希望实体框架能够证明更有价值。 / p>
EF 4.0中的新功能非常引人注目，至少和大多数辩论都围绕着L2S vs EF与EF 3.5 SP1进行比较。 EF 4.0具有POCO，持久性无知，延迟加载，T4模板，N层支持以及更多功能。
就个人而言，我会支持EF 4.0，但仍处于测试阶段，直到今年年底才会RTM，所以这取决于你的日程安排。也就是说，从Linq迁移到SQL比从nHiberante或其他技术迁移更容易，因此如果您需要明天上线，可以选择使用EF 4.0的Beta 1或者使用Linq转换为SQL。
到目前为止，Beta 1已经获得了很好的评价并使用了EFPocoAdapter（Beta 1的前身）我很乐意推荐它。
答案 1 :(得分：1)
我相信，从中期来看，Linq将继续存在。它的学习曲线比EF短（或者至少对我而言），所以我就这样了。
答案 2 :(得分：0)
我将直接使用LINQ to Entities进入实体框架（EF）。 MS已经宣布EF是未来数据库工作的前进方向，它是所有新产品的技术。因为大多数开发人员都没有使用LINQ，所以会有一个学习曲线，但是一旦你过去，代码就会自然而然地出现。
EF更面向对象，因此它与LINQ to SQL有不同的感觉。例如，在EF中，您表示与对象的关系，其中LINQ to SQL允许您指定外键索引。即将推出的版本将更容易使用。您可能会发现遵循ADO.NET Team Blog。
非常有用乔
答案 3 :(得分：0)
我会去.Net 4.0的EF。不仅我听说L2S处于维护模式，而且新版本的EF也得到了很大的改进。对我来说最重要的是this。
答案 4 :(得分：0)
LINQ2SQL是在C＃团队中创建的，用于将ORM SQL结构转换为类并在C＃中查询它们。 EF是由ADO.NET DB团队开发的，因此它更适合于数据库方面，而不是程序员方面。由于ADO.NET是微软的数据库平台，当然他们会支持它比LINQ2SQL更多，但这并不是说它们不会并行开发。
这是一个link to a page，它与LINQ2SQL和EF进行了并排比较。这至少没有所有要点，而是许多重要的要点。
答案 5 :(得分：0)
Linq和实体框架是Microsoft同时开发的两种技术。 Linq只是允许对内存中对象进行查询，而实体框架会执行更重的数据库内容。由于实体框架的延迟，Linq也需要对查询有用。
如果您从新系统开始，实体框架将是我个人的选择。我喜欢实体模型，因为它使得处理事务变得更容易，并且更容易处理表之间的关系。对于我正在处理的项目，我决定使用Entity模型作为数据库层，并在此之上构建所有其他功能。通过链接到正确的事件，我可以跟踪所有编辑，插入和删除，因此有一个入口点，从我可以开始我的日志。实体模型还允许我建立一个简单的网站（使用动态数据站点逻辑），现在用于数据输入，直到我们有更多的时间来创建更好的解决方案。 （因为，目前我们所需要的只是数据输入功能。）
然而，在一开始，实体框架有点难以使用，你可能会因为沮丧而几次敲打你的脑袋。但如果你不放弃，这种技术将是非常有益的......
答案 6 :(得分：0)
EF需要进一步发展。有些东西仍然缺乏，例如隐式延迟加载，数据库聚焦而不是领域模型聚焦等。阅读更多关于不信任投票：http://blogs.msdn.com/timmall/archive/2008/06/24/vote-of-no-confidence.aspx