我应该开始使用 LINQ To SQL 吗？

Posted 2023-04-11

【中文标题】我应该开始使用 LINQ To SQL 吗？

【英文标题】：Should I start using LINQ To SQL?

【发布时间】：2010-09-10 00:43:45

【问题描述】：

目前我正在使用 NetTiers 来生成我的数据访问层和服务层。我使用 NetTiers 已有 2 年多了，发现它非常有用。在某些时候我需要查看 LINQ，所以我的问题是......

有其他人从 NetTiers 转到 LINQ To SQL 吗？ 这种转变是好事还是坏事？ 有什么需要注意的吗？ 你会推荐这个开关吗？

基本上我会欢迎任何想法 .

【参考方案1】：

没有 见 #1 您应该注意标准抽象开销。它也是非常基于当前状态的 SQL Server。 您使用的是 SQL Server，那么可能。如果您现在正在将 LINQ 用于其他事情，例如 XML 数据（很棒）、对象数据、数据集，那么是的，您应该可以切换为所有这些都使用统一的数据语法。就像提到的lagerdalek 一样，如果它没有损坏，请不要修复它。 通过快速浏览 .netTiers 应用程序框架，我想说，如果您已经对该解决方案进行了投资，那么它似乎给您提供的不仅仅是一个简单的数据访问层，您应该坚持下去。

根据我的经验，LINQ to SQL 对于中小型项目来说是一个很好的解决方案。这是一个 ORM，它是提高生产力的好方法。它还应该为您提供另一层抽象，允许您将下面的层更改为其他内容。 Visual Studio 中的设计器（我也相信 VS Express）非常简单易用。它为您提供对象映射的通用拖放和基于属性的编辑。

@ Jason Jackson - 设计器允许您手动添加属性，但是您需要指定该属性的属性，但是您这样做一次，可能比最初将表格拖入设计器，但是每次更改数据库本身只需要一次。这与其他 ORM 并没有太大区别，但是您是正确的，它们可以使这变得更容易，并且只找到那些已更改的属性，甚至为此类需求实施某种重构工具。

资源：

Why use LINQ to SQL? Scott Guthrie on LINQ to SQL 10 Tips to Improve your LINQ to SQL Application Performance LINQ To SQL and Visual Studio 2008 Performance Update Performance Comparisons LINQ to SQL / ADO / C# LINQ to SQL 5 Minute Overview

请注意，Parallel LINQ 正在开发中，以便在多核机器上实现更高的性能。

【参考方案2】：

我尝试在一个小项目上使用 Linq to SQL，认为我想要一些可以快速生成的东西。我在设计师中遇到了很多问题。例如，每当您需要向表中添加列时，您基本上必须在设计器中删除并重新添加表定义。如果您在表格上设置了任何属性，那么您必须重新设置这些属性。对我来说，这确实减慢了开发过程。

LINQ to SQL 本身很好。我真的很喜欢可扩展性。如果他们可以改进设计师，我可能会再试一次。我认为该框架将受益于针对 Web 开发等断开连接模型的更多功能。

查看Scott Guthrie's LINQ to SQL series 的博客文章，了解如何使用它的一些很好的示例。

【讨论】：

一个很好的网站，向您展示如何使用部分类，修改 LINQ to SQL 生成的源文件，同时仍然能够刷新设计器生成的源。 dotnetslackers.com/articles/csharp/…

【参考方案3】：

NetTiers 非常适合生成重且健壮的 DAL，我们在内部将它用于核心库和框架。

在我看来，LINQ（在它的所有化身中，但特别是我认为您要求使用 SQL）非常适合快速数据访问，我们通常将它用于更敏捷的情况。

如果不重新生成代码或 dbml 层，这两种技术都很难改变。

话虽如此，正确使用 LINQ 2 SQL 是一个非常强大的解决方案，由于它易于使用，您甚至可能会开始将它用于未来的开发，但我不会为此丢弃您当前的 DAL - 如果它没破……

【参考方案4】：

我的经验告诉我，使用 linq 可以更快地完成任务，但是对数据库的实际操作会更慢。

所以...如果您有一个小型数据库，我会说去吧。如果没有，我会在更改之前等待一些改进

【讨论】：

您的经验如何告诉您“对数据库的实际操作较慢？”您应该包含对您所做的性能测试的描述，以便人们知道您不仅仅是在编造。

【参考方案5】：

我现在在相当大的项目（大约 150 个表）上使用 LINQ to SQL，它对我来说效果很好。我使用的最后一个 ORM 是 IBatis，它运行良好，但需要大量工作才能完成映射。 LINQ to SQL 对我来说执行得非常好，而且到目前为止已证明非常容易开箱即用。在过渡过程中肯定有一些差异需要克服，但我建议使用它。

旁注，我从未使用过或阅读过有关 NetTiers 的信息，因此我不会低估它的有效性，但总的来说 LINQ to SQL 已被证明是一种非常可行的 ORM。

【参考方案6】：

我们的团队曾经使用过 NetTiers，发现它很有用。但是......我们使用它的次数越多，我们发现它的头痛和痛点就越多。例如，每当您对数据库进行更改时，您都需要使用 CodeSmith 重新生成 DAL，这涉及到：

在 3 个独立的项目中重新生成数千行代码 重新生成数百个存储过程

也许还有其他方法可以做到，但这是我们必须做的。源代码的重新生成是好的，可怕的，但是好的。真正的问题来自存储过程。它没有清除任何未使用的存储过程，因此如果您从架构中删除表并重新生成 DAL，则该表的存储过程不会被删除。此外，这对于数据库更改脚本来说变得相当头疼，我们必须将旧的数据库结构与新的数据库结构进行比较，并创建一个更改脚本来更新客户端安装。这个脚本可能会跑上几万行sql代码，如果执行有问题，总是有问题，解决起来很痛苦。

然后灯亮了，NHibernate 作为 ORM。它当然有一个加速时间，但它非常值得。有大量的支持，所以如果有什么你需要做的，很可能以前已经做过了。它非常灵活，允许您控制它的各个方面，然后是一些方面。它也变得越来越容易使用。 Fluent Nhibernate 正在兴起并成为摆脱所需 xml 映射文件的好方法，NHibernate Profiler 提供了一个出色的界面来查看幕后发生的事情，从而提高效率并消除冗余。

从 NetTiers 迁移到 NHibernate 很痛苦，但这是一种好的方式。它迫使我们转向更好的架构并重新评估功能需求。 NetTiers 提供了大量的数据访问代码，通过它的 id 获取这个实体，通过它的外键获取这个另一个实体，获取这个和那个的 tlist 和 vlist，但其中大部分是不必要的和未使用的。 NHibernate 仅在需要时使用通用存储库和自定义存储库，从而减少大量未使用的代码并真正提高可读性和可靠性。

【讨论】：

使用 netTiers，您可以将其设置为使用参数化 sql 而不是存储过程。这使您免于数据库中的 sp 混乱。

您好，我们正在努力在 .netTiers (v3.0) 的下一版本中消除/减少这些开销和痛点。谢谢 -Blake Niemyjski