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

Question

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

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

基本上我会欢迎任何想法

Answer 1

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

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

@ Jason Jackson - Designer允许您手动添加属性，但是您需要指定该属性的属性，但是这样做一次，它可能比最初拖动表花费3分钟然而，只有在数据库本身的每次更改时才需要进入设计器。这与其他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正在开发中，以便在多核计算机上实现更高的性能。

Answer 2

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

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

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

Answer 3

NetTiers非常适合生成繁重而强大的DAL，我们在内部使用它来构建核心库和框架。

正如我所看到的，LINQ（在它的所有版本中，但特别是因为我认为你要求SQL）非常适合快速访问数据，我们通常将它用于更敏捷的情况。

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

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

Answer 4

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

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

Answer 5

我现在在相当大的项目上使用LINQ to SQL（大约150个表），它对我来说非常好。我使用的最后一个ORM是IBatis，它运行良好但是需要大量的工作来完成你的映射。 LINQ to SQL对我来说表现非常好，到目前为止已经证明非常容易使用。确切地说，在转换过程中你必须克服一些差异，但我建议使用它。

旁注，我从未使用过或读过有关NetTiers的内容，所以我不会忽视它的有效性，但一般来说LINQ to SQL已被证明是一种非常可行的ORM。

Answer 6

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

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

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

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

从NetTiers迁移到NHibernate一直很痛苦，但是很好。它迫使我们进入更好的架构并重新评估功能需求。 NetTiers提供了大量的数据访问代码，通过其id获取此实体，通过其外键获取该另一个实体，获取此列表和vlist，但大部分都是不必要和未使用的。 NHibernate只有一个通用的存储库和自定义存储库，只需要减少大量未使用的代码，真正提高了可读性和可靠性。