Linq 2 SQL 或 Linq 实体答案

【问题标题】：Linq 2 SQL or Linq EntitiesLinq 2 SQL 或 Linq 实体
【发布时间】：2008-12-13 03:10:22
【问题描述】：

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

我也在对 ADO.net 数据服务进行一些研究。

【问题讨论】：

标签： .net linq linq-to-sql linq-to-entities ado

【解决方案1】：

是的，同意 Slace。

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

例如，我最近从一个工作项目中删除了 Entity Framework，因为它在过去几周内非常稳定地使用它，因为它不能满足我的需求，主要是因为：-

things you can't do in Linq to Entities（例如映射到 .net 枚举类型 (grr) 以及如果您尝试通过调用函数或方法调用来在 linq 查询语句中获得幻想，那么几乎每时每刻都会收到“NotSupportedException”的恶化（见链接））。
缺乏原生延迟加载（我知道有诸如 EF Lazy LoadGen 之类的工具来促进这一点，但我不想加入它）。

除此之外，命令和框架看起来简单明了，我选择 EF 的原因是：

我认为 EF 更多地针对企业开发，并认为 L2S 更适合业余爱好者并且是一个有限的框架。然而，随着进一步的理解和个人的理解，在 EF 中不需要任何我不能用 L2S 做的事情，我对 L2S 很满意。特别是如果它适合 stackoverflow，可扩展性和效率对我来说都涵盖在内。
多个 DBMS 的选项（不过，我还没有看到这个选项）
据传微软是dropping support and investment on Linq to SQL。
我喜欢这样一个事实，您可以在 EF .edmx 中更新表和 DB 更改，而无需删除现有的模式模型（在 Linq to SQL 中您必须这样做）。不过，除非您自定义了 L2S 架构 (.dbml) 中的任何属性，否则这不会很烦人。

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

我很想选择 EF，我真的不知道如何看待 L2S 与 EF 的失败，如果 L2S 真的是一只死鸭，耸耸肩。不可否认，我对 EF 的主要抱怨是 NotSupportedException - 如果我可以在 linq 中执行方法调用而不得到这个，我可以绕过延迟加载......

【讨论】：

【解决方案2】：

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

MS SQL Server 作为数据库引擎
RAD 开发
只需要 1 - 1 个类映射

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

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

【讨论】：

Linq2SQL 允许一些子类化，但它不是很灵活。您必须使用一列作为类型鉴别器。我想在分层表中执行此操作（其中 fk 到同一个表的存在表明与同一个表中的父级的关系），但无法使其工作。
确实如此，因为 LINQ to SQL 在设计时并未考虑到子类化，而 EF 是。但这 - 连同 EF 的其他功能 - 增加了复杂性，因此开销更大。
你必须有一个非常扁平/无聊/简单的表格设计才能轻松使用任何 MS 功能（强类型 TableAdapters、Linq2Sql 等）

【解决方案3】：

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

【讨论】：

希望了解更多关于您扩展 L2S 的方式
可以分享一些你的代码吗，对我们很有价值
我用 LINQ2SQL 完成的大量工作可以在我的博客上找到：farm-fresh-code.blogspot.com

【解决方案4】：

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

我在两者之间的整体想法涵盖了here，但从那以后我已经软化了一点，请参阅here。

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

【讨论】：

【解决方案5】：

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

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

【讨论】：

【解决方案6】：

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

Linq-to-Entities 很笨拙，如果您尝试使用任何应该将其与 L2S 分开的“高级”功能，那么您将不得不开始使用 XML 编辑器编辑您的 EDMX 模型文件（您的很快就会在设计器中遇到“限制”，Microsoft 推荐的唯一解决方法/解决方案是使用 XML 编辑器手动调整 EDMX）。最重要的是，它往往会生成非常糟糕/低效的 SQL 查询。

Microsoft 表示，Entity Framework 的下一个版本会更好，并将支持 L2S 的所有优点。但是下一个版本不会很快发布，所以在此之前 L2S 是您最好的选择。

【讨论】：

【解决方案7】：

我建议查看适用于 ORM 的非 Microsoft 解决方案。 nHibernate 是一个很好的解决方案，它具有这两个框架的所有优点以及更多优点。是的，它的学习曲线更陡峭，但流畅的 nHibernate 对此有所帮助。值得付出努力。

【讨论】：

【解决方案8】：

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

两种技术都有问题（NHibernate 也有问题）。

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

【讨论】：

【解决方案9】：

这是一个很老的问题，但投票最多的 LinqToSql 啦啦队让我很担心。 LinqToSql 有很大的缺点。

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

The drawbacks of adopting Linq To Sql

也就是说，EntityFramework 也有明显的缺点。

有很多更好的选择（NHibernate 是目前最好的选择）。

【讨论】：

我不同意。与（我假设）您发布的网站的开发人员一样，因为 StackOverflow 使用 L2S 作为其持久性机制。它并不适合所有人，但我在从 ASP.NET 访问多个数据库的企业环境中取得了巨大的成功。如果您已经购买了整个 MS 堆栈并且可以接受与您的 DB 表一对一绑定的贫血对象，那么 L2S 是一个很好的解决方案。

【解决方案10】：

在我们尝试进行更新之前，我们认为 L2S 很棒。然后就很可怜了。我的同事在做大部分工作，而我做其他事情。他谈到了 EF 以及过度可配置性使其使用变得混乱的方式。

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

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

碰巧我已经改变了我对整个 EF 与 L2S 事情的立场，但这并没有改变这样一个事实，即仅仅因为它表达了与你自己不同的观点而对某件事投反对票是幼稚的，并且完全违背了精神StackOverflow 的。

【讨论】：

【解决方案11】：

如今，Linq to SQL 是一条死胡同，因为 Microsoft 不会再更新它了。我在自己的项目中使用了一段时间，但与真正的 SQL 相比，我发现它的功能不足。当然，在短期内运行起来似乎更容易，但在应用程序的开发周期中，您会发现您更喜欢 SQL 的强大功能。

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

您应该记住的另一件事是，SQL 和您的应用程序之间的额外层有其自身的成本。速度差异不是您容易注意到的，但确实存在。

我个人建议刚开始的人应该直接毕业学习 SQL，而不要错过 LINQ to SQL。

【讨论】：

死胡同？是吗？我不太确定...reddevnews.com/blogs/weblog.aspx?blog=3016
-1 不是来自我，而是你的“真正的 SQL”——你可以将 L2S 指向 SPROC 和 UDF 方法，以将其用作刚性 TSQL 层之上的 DAL。跨度>
嗨，Marc，我不介意使用“-”来表达不同意见。这是意料之中的 :)... 但是我为什么要将 L2S 作为 DAL 而不是 SPROC？为什么我不在我的代码中直接使用 Proc？ L2S 是给初学者喂 ORM 的。我认为没有任何令人信服的理由来采用它。（这里有更多'-'）
对我来说听起来就像一个 SQL 瘾君子感到受到威胁并试图贬低一项技术而不真正学习它......
对查询的编译时间检查太好了，无法传递。我是一个 T-SQL 迷，但 L2S 的强大功能和简单优雅实在是太令人难以忘怀了。你的损失。