5

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

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

4

11 回答 11

13

是的，同意 Slace。

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

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

  1. 您在 Linq to Entities 中不能做的事情（例如映射到 .net 枚举类型 (grr) 以及如果您尝试通过调用函数来在 linq 查询语句中花哨的话，几乎每次都收到“NotSupportedException”的恶化或方法调用（见链接））。
  2. 缺乏本机延迟加载（我知道有诸如 EF Lazy LoadGen 之类的工具来促进这一点，但这不是我想要加入的东西）。

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

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

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

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

于 2008-12-14T05:01:56.693 回答
8

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

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

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

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

于 2008-12-13T03:18:09.950 回答
3

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

于 2008-12-13T03:16:39.547 回答
3

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

我在两者之间的整体想法在这里涵盖了，但从那时起我已经软化了一点，请参见这里。

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

于 2008-12-13T09:34:09.580 回答
2

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

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

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

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

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

于 2008-12-13T03:27:13.067 回答
0

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

于 2008-12-13T06:11:06.777 回答
0

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

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

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

于 2008-12-13T07:54:12.357 回答
0

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

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

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

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

于 2009-02-03T14:57:25.587 回答
0

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

不要使用 Visual Studio 2008 LinqToSql O/R 设计器

采用 Linq To Sql 的弊端

也就是说，EntityFramework 也有很大的缺点。

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

于 2009-08-29T11:57:56.847 回答
-1

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

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

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

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

于 2008-12-13T05:01:17.633 回答