Linq 2 SQL或Linq实体

Question

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

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

Answer 1

是的，同意Slace的意见。

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

例如，我最近在一个工作项目中扼杀了实体框架，在过去的几周内完成了它，因为它不能满足我的需求，主要是因为： -

1. Linq to Entities中你不能做的事情 （例如映射到.net枚举类型（grr）和几乎每一次接收'NotSupportedException'的加重，如果你试图通过调用函数来获得你的linq查询语句中的幻想或方法调用（见链接））。
2. 缺乏本地延迟加载（我知道有一些工具，如EF Lazy LoadGen来促进这一点，但它不是我想要加入的东西）。

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

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

进一步阅读（另一篇SO帖子）：
LINQ to SQL死了还是活着？

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

Answer 2

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

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

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

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

Answer 3

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

Answer 4

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

我在这里介绍了两者之间的整体想法，但是从那时起我已经软化了一点，看到这里 。

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

Answer 5

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

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

Answer 6

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

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

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

Answer 7

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

不要使用Visual Studio 2008 LinqToSql操作系统设计器

采用Linq To Sql的缺点

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

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

Answer 8

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

Answer 9

没有人可以肯定地说你有什么更好的。

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

我正在使用Linq-to-SQL并且非常满意它。 我认为Linq-to-SQL中的问题少于EF ^ _ ^。

Answer 10

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

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

---

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

事实上，我已经改变了我对整个EF vs L2S事物的立场，但这并没有改变这样一个事实：仅仅因为它表达了一种与你自己不同的观点而且仅仅是因为它表达了与你自己不同的观点而且完全违背了StackOverflow的精神。

Answer 11

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

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

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

我个人建议那些刚开始的人应该直接升级到SQL，并给LINQ to SQL一个错过。