Linq 2 SQL或Linq实体

Question

我开始设计一个新的应用程序，我想知道的是人们对Linq2SQL或Linq2Entities的看法，他们认为这是更好的快速开发技术。

我也在研究ADO.net数据服务。

Answer 1

是的，同意Slace。

请注意您选择的框架，以确保它满足您的所有需求。

例如，我最近在一个工作项目中强化了实体框架，因为它不能满足我的需求，主要是因为： -

1. things you can't do in Linq to Entities（例如映射到.net枚举类型（grr）和几乎每一次接收'NotSupportedException'的加重，如果你试图通过调用函数或方法来获得你的linq查询语句中的幻想电话（见链接））。
2. 缺乏原生的Lazy Loading（我知道有一些工具，例如EF Lazy LoadGen来促进这一点，但这不是我想要加入的东西）。

除此之外，命令和框架似乎是直截了当的，而且我使用EF的原因是：

1. 我认为EF的目标更多是企业发展的目标，并认为L2S更适合业余爱好者，而且是一个有限的框架。然而，通过进一步的理解和个人，在EF中我不需要任何东西我无法做到L2S，我对L2S很满意。特别是如果它适合stackoverflow，我可以满足可扩展性和效率。
2. 多个DBMS的选项'（我现在还没看到这个）
3. 传闻微软是dropping support and investment on Linq to SQL。
4. 我喜欢这样一个事实：您可以更新EF .edmx中的表和数据库更改，而无需删除现有的模式模型（您必须在Linq to SQL中执行此操作）。虽然，除非您在L2S架构（.dbml）中自定义任何属性，否则不会超级烦人。

进一步阅读（另一篇SO帖子）：
Is LINQ to SQL Dead or Alive?

我很想选择EF，我真的不知道如何制造L2S与EF的比赛，如果L2S真的是一个死鸭，耸耸肩。我承认使用EF的主要抱怨是NotSupportedException - 如果我可以在linq中执行方法调用而没有得到这个，我可以绕过延迟加载......

Answer 2

如果您满足以下设计要求，我就是LINQ to SQL的忠实粉丝：

• MS SQL Server作为数据库引擎
• RAD开发
• 1 - 1类映射就是所需要的

我没有对Entity Framework做过大量工作，但据我所知和我所做的是，当它从LINQ to SQL使用的同一数据库生成时，它没有那么好的性能。 / p>

性能较低是由于Entity Framework的性质，它使用ADO而不是您正在使用的数据库服务器的特定提供程序。

Answer 3

我想说，对于简单到中等的数据库模式，Linq2SQL运行良好，更易于设置和使用。这是我用于ORM的一些小调整，通过部分类来支持验证和授权/审计。我使用DBML设计器并添加我的表/关系。我更改了DataContext以使其变得抽象，并构建了一个具体的实现，它允许我提供我的表值函数/存储过程（映射到数据上下文中作为方法）的实现，这些实现为审计和授权提供了钩子。我在OnValidate和OnLoad的实体类上实现了部分方法，以在表级执行验证和授权。我发现这几乎是我所需要的。最近，我一直在为具体数据上下文定义一个接口和包装器，以便允许我在单元测试中模拟它。

Answer 4

与ADO.NET数据服务（您提到）一起使用，实体框架是开箱即用的框架。如果要使用LINQ-to-SQL（通过ADO.NET数据服务）更新数据，则需要执行一些工作来实现IUpdatable。幸运的是，我一直在写关于this week的博客。

我对两者之间的整体想法都有涵盖here，但从那时起我已经软化了一点，见here。

基本上，目前我更喜欢LINQ-to-SQL，但我希望EF在下一版本中更有用。因此，我正在努力让LINQ-to-SQL与ADO.NET数据服务一起工作。

Answer 5

我认为Linq 2 Sql是一个很好的选择。几点：

• 这真的很快，我记得在L2S测试版期间在Rico Mariani's Performance Tidbits阅读了一篇博客文章，在那里他测得它几乎和普通的旧ADO.Net一样快，那是在测试期间。
• 如果您愿意，可以同时执行linq查询以及使用存储过程和良好的旧SQL，并且仍然可以为您完成数据对象映射。
• Stackoverflow使用L2S的事实证明它可以在大型网站上运行。
• 它比实体框架轻得多，根据您的需要，这是好的和坏的。一般来说，如果您的需求不是超级先进的，通常可以很快解决任何问题。

Answer 6

我的投票是Linq-to-SQL。它适合您的快速开发场景;易于上手，易于使用。此外，它还可以从Linq表达式生成高效/高效的SQL查询。

Linq-to-Entities非常笨重，如果您尝试使用任何本应将其设置为远离L2S的“高级”功能，那么您将不得不使用XML编辑器开始编辑EDMX模型文件（您'很快就会遇到设计师的“限制”，微软推荐的唯一解决方法/解决方案就是使用XML编辑器手动操作EDMX。最重要的是，它往往会产生非常差/低效的SQL查询。

微软表示，下一版本的Entity Framework将会更好，并将支持L2S的所有好处。然而，下一个版本不会很快发布，所以在那之前L2S是你最好的选择。

Answer 7

我建议您查看ORM的非Microsoft软件解决方案。 nHibernate是一个很好的解决方案，拥有这两个框架的所有好处以及更多。是的，它的学习曲线更陡峭，但流利的nHibernate对此有所帮助。值得努力。

Answer 8

没有人能说肯定 更好。

两个技术人员都有问题（NHibernate也存在问题）。

我正在使用Linq-to-SQL并且非常满意。对于我的观点，Linq-to-SQL中的问题少于EF ^ _ ^。

Answer 9

我们认为L2S很棒，直到我们尝试更新。然后它很可悲。我做其他事情时，我的同事正在完成大部分工作。他谈到了EF以及过度配置使得它使用起来混乱的方式。

我建议，既然我们以MSSQL为目标并且不会改变，那么他可能会破解所有数据库提供程序的抽象内容。一段时间后，他告诉我这是一个很好的建议，他的代码更简单，更难以维护。

---

我很好奇这个答案被投票 down 的基础。它描述了实际经验，并讨论了另一种策略以及该方法的相对成功。向下投票是针对误导，事实不正确或只是简单拖钓的答案。

碰巧我改变了我对整个EF vs L2S事物的立场，但这并没有改变这样一个事实，即仅仅因为它表达了与你自己不同的观点而进行了投票，这种观点是婴儿的，并且与精神完全背道而驰StackOverflow。

Answer 10

这是一个非常古老的问题，但LinqToSql对最高投票答案的啦啦队关注我。 LinqToSql存在明显的缺点。

Do not use the Visual Studio 2008 LinqToSql O/R Designer

The drawbacks of adopting Linq To Sql

也就是说，EntityFramework也有很多缺点。

现有更多更好的选择（NHibernate现在是最好的选择）。

Answer 11

Linq to SQL如今已经走到了尽头，因为微软不会再对其进行更新了。我为自己的项目使用了一段时间，但我发现它与真正的SQL相比功能不足。当然，在短期内运行似乎更容易，但在应用程序的开发周期中，您会发现您更喜欢SQL的强大功能。

我认为LINQ TO SQL只应该由那些严重依赖于框架的抽象层并且没有时间/精力/欲望来追求SQL的人采用。

您应该记住的另一件事是SQL和您的应用程序之间的额外层有自己的成本。速度差异不是你容易注意到的，但它就在那里。

就我个人而言，我建议那些刚开始学习的人应该直接学习SQL，并且错过LINQ to SQL。