logo标签列表

Linq 2 SQL or Linq Entities

.netlinqlinq-to-sqllinq-to-entitiesado
5

我开始设计一个新的应用程序，想知道人们对Linq2SQL或Linq2Entities的意见，以及他们认为哪种技术更适合快速开发。

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

11个回答
13

同意Slace的观点。

但是选择框架时要小心，确保它能满足您的所有需求。

例如，最近我从一个工作项目中剔除了Entity Framework，因为我在过去几周里一直在与它紧密合作，但由于以下原因它无法满足我的需求：

  1. Linq to Entities无法支持的内容（例如映射到 .net 枚举类型（grr），以及如果在 Linq 查询语句中调用函数或方法调用时会在几乎每个地方收到“NotSupportedException”的抱怨（请参见链接））。
  2. 缺乏本地惰性加载（我知道有一些工具例如EF Lazy LoadGen可以实现这个功能，但这不是我想要的东西）。

除此之外，命令和框架似乎非常简单明了，我选择EF的原因是：

  1. 我认为EF更适合企业开发，并认为L2S更适合业余爱好者，是一个有限的框架。然而通过进一步理解并且个人经验证明，我没有需要用EF而不能使用L2S完成的任务，我对L2S非常满意。特别是如果它适合stackoverflow，那么可扩展性和效率就已经涵盖了我的需求。
  2. 支持多个DBMS（虽然我还没有亲眼见到它的运作）
  3. 有传言称Microsoft正在放弃对Linq to SQL的支持和投资。
  4. 我喜欢在EF .edmx中更新表和数据库更改而不必删除现有模式模型（在Linq to SQL中必须这样做）。尽管这不是非常烦人，除非您已经自定义了L2S模式（.dbml）中的任何属性。

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

我想使用EF，但我真的不知道如何对比L2S和EF，并且如果L2S真的是一只死鸭子，我无能为力。我主要抱怨EF中的NotSupportedException - 如果我在linq中执行方法调用而不会遇到这个异常，我就可以绕过延迟加载...

8

如果满足以下设计要求，我很喜欢LINQ to SQL：

  • 使用MS SQL Server作为数据库引擎
  • RAD开发
  • 只需要1对1的类映射

我没有在Entity Framework上做过太多的工作，但从我所了解和做过的事情来看，与从相同的数据库生成的LINQ to SQL相比，它的性能不够好。

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

Linq2SQL 允许一些子类，但不是非常灵活。您必须将一个列用作类型鉴别器。我想在分层表中做到这一点（其中对同一表的 fk 的存在显示与同一表中的父项的关系），但无法使其工作。 - tvanfosson
这是真的，因为LINQ to SQL并没有考虑到子类化的设计，而EF则有。但是，这个特性以及EF的其他特性增加了复杂性，因此增加了更大的开销。 - Boyan
你必须拥有一个相当平坦/无聊/简单的表格设计，才能轻松使用任何 MS 功能（强类型 TableAdapters、Linq2Sql 等）。 - user7116
3
我认为对于简单到中等的数据库模式，Linq2SQL非常适用且易于设置和使用。这是我使用的ORM，通过部分类的小调整来支持验证和授权/审计。我使用DBML设计器并添加我的表格/关系。我更改DataContext使其抽象化，并构建一个具体实现，允许我提供我的表值函数/存储过程的实现（它们映射到数据上下文作为方法），为审计和授权提供钩子。我在实体类上实现了OnValidate和OnLoad的部分类方法，以在表级别进行验证和授权。我发现这几乎就是我需要的全部。最近，我还定义了一个接口和包装器，用于具体数据上下文，以便在单元测试中模拟它。
很想听听您如何扩展L2S的方法。 - RobS
你能分享一些你的代码吗？对我们来说太有价值了。 - Mostafa
我在LINQ2SQL方面所做的相当多的工作可以在我的博客上找到：http://farm-fresh-code.blogspot.com - tvanfosson
3

对于与 ADO.NET Data Services（您提到过）一起使用的情况，Entity Framework 是开箱即用的。如果您想要通过 LINQ-to-SQL（通过 ADO.NET Data Services）更新数据，您需要做一些工作来实现 IUpdatable。幸运的是，我这周已经在博客上写了关于这方面的内容这里。

我对两者的整体看法在这里有涉及，但自那以来我有点软化了，可以看这里。

基本上，目前我更喜欢 LINQ-to-SQL，但我期望在下一个版本中 EF 更易用。这就是为什么我正在努力使 LINQ-to-SQL 与 ADO.NET Data Services 协同工作。

2
我认为Linq 2 Sql是一个非常好的选择。以下是几点：
  • 它非常快，我记得在L2S beta期间读过一篇博客文章，作者是Rico Mariani's Performance Tidbits，他测量了它的速度几乎与普通的ADO.Net一样快，而且那还是在beta版本中。
  • 你既可以使用linq查询，也可以使用存储过程和传统的sql语句，同时仍然可以完成数据到对象的映射。
  • Stackoverflow使用L2S这一事实证明它可以在大型网站上运行。
  • 它比Entity Framework轻量级得多，这对你的需求有利有弊。一般来说，如果你的需求不是超级高级的，你通常可以很快地解决任何问题。
1

我推荐使用Linq-to-SQL。它适合快速开发场景，易于上手和使用。此外，它能从Linq表达式生成良好/高效的SQL查询。

Linq-to-Entities相对笨重，如果你尝试使用任何“高级”功能以使其与L2S区分开来，则必须开始使用XML编辑器编辑EDMX模型文件（在设计师中会遇到“限制”，微软建议的唯一解决方案是使用XML编辑器手动操作EDMX）。此外，它往往会生成非常糟糕/低效的SQL查询。

微软表示下一个版本的Entity Framework将更加出色，并且将支持L2S的所有优点。但是，下一个版本不会很快发布，因此在那之前，L2S是你最好的选择。

0

我们曾经认为L2S很棒，直到我们尝试进行更新。然后它就变得很糟糕了。我的同事负责大部分工作，而我则做其他事情。他谈到了EF以及过度可配置性带来的混乱使用方式。

我建议说，既然我们的目标是MSSQL，而且这不会改变，他可以删除所有数据库提供程序抽象的内容。一段时间后，他告诉我这是一个好建议，他的代码更简单，维护起来也不那么麻烦了。

我很好奇这个回答被投票 反对 的基础是什么。它描述了实际经验，并讨论了另一种策略及其相对成功的情况。投票反对是针对那些误导性、事实不正确或纯粹是恶意评论的答案。

碰巧我已经改变了我的立场，关于整个 EF vs L2S 的问题，但这并不改变一个事实，那就是仅仅因为表达了与你不同的观点而将其投票反对是幼稚的，完全违背了 StackOverflow 的精神。

0
我建议使用非Microsoft的ORM解决方案。nHibernate是一个很好的解决方案，它拥有这两个框架的所有好处，更多的功能。是的，它的学习曲线更陡峭，但是流畅的nHibernate可以帮助您应对挑战。这值得付出努力。
0

没有人能够确定哪种技术更好。

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

我正在使用Linq-to-SQL，并且对它感到非常满意。在我看来，Linq-to-SQL的问题比EF少得多 ^_^。

0
我不敢苟同。我猜（仅仅是猜测），您发布帖子的网站的开发人员们也持有相同观点，因为StackOverflow使用L2S作为其持久性机制。它并非人人都适用，但在企业环境下，我通过ASP.NET从多个数据库访问数据时，它取得了极大成功。如果您已经采用了整个微软技术栈，并且可以接受贫血对象与DB表一对一绑定，L2S是一个很好的解决方案。 - mattmc3
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接