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

StackOverflow https://stackoverflow.com/questions/81376

题

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

  1. 还有其他人从 NetTiers 转向 LINQ To SQL 吗？
  2. 这种转变是好事还是坏事？
  3. 有什么我应该注意的吗？
  4. 您会推荐这个开关吗？

基本上，我欢迎任何想法。

有帮助吗？

解决方案

  1. 不
  2. 参见#1
  3. 您应该注意标准抽象开销。而且它的当前状态非常基于 SQL Server。
  4. 那么也许您正在使用 SQL Server。如果您现在正在将 LINQ 用于其他用途，例如 XML 数据（很棒）、对象数据、数据集，那么您应该可以切换为对所有这些数据使用统一的数据语法。喜欢 拉格达莱克 提到如果它没有坏就不要修理它。快速浏览一下 .netTiers 应用程序框架，我想说，如果您已经对该解决方案进行了投资，那么它似乎为您提供的不仅仅是简单的数据访问层，您应该坚持使用它。

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

@ 贾森·杰克逊 - 设计器确实允许您手动添加属性，但是您需要指定该属性的属性，但是您执行一次，可能比最初将表拖到设计器中需要多 3 分钟，但这只是必要的数据库本身每次更改一次。这与其他 ORM 并没有太大不同，但是您是对的，它们可以使这变得更加容易，并且只查找那些已更改的属性，甚至可以为此类需求实现某种重构工具。

资源：

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

其他提示

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

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

查看 Scott Guthrie 的 LINQ to SQL 系列 博客文章中的一些关于如何使用它的很好的例子。

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

在我看来，LINQ（在它的所有版本中，但具体来说，我认为您要求的是 SQL）非常适合快速数据访问，并且我们通常将它用于更敏捷的情况。

如果不重新生成代码或 dbml 层，这两种技术的更改都非常不灵活。

话虽这么说，正确使用 LINQ 2 SQL 是一个相当强大的解决方案，您甚至可能开始使用它进行未来的开发，因为它易于使用，但我不会为了它而放弃您当前的 DAL - 如果它没有损坏。 ..

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

所以...如果你有一个小数据库，我会说去吧。如果没有，我会等待一些改进再更改

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

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

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

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

也许还有其他方法可以做到这一点，但这就是我们必须做的。源代码的重新生成还可以，有点吓人，但是还可以。真正的问题来自存储过程。它不会清除任何未使用的存储过程，因此，如果您从架构中删除表并重新生成 DAL，则该表的存储过程不会被删除。此外，这对于数据库更改脚本来说非常令人头痛，我们必须将旧数据库结构与新数据库结构进行比较，并创建一个更改脚本来更新客户端安装。该脚本可能会运行数万行 sql 代码，如果执行它时出现问题（这种情况总是存在的），那么解决它会非常痛苦。

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

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

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top