logo标签列表

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

c#linqlinq-to-sql.nettiers
8

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

  1. 是否有其他人从NetTiers转向LINQ To SQL？
  2. 这个转换是好事还是坏事？
  3. 有什么需要注意的吗？
  4. 你会推荐这个转换吗？

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

6个回答
5
  1. 不
  2. 参见＃1
  3. 你应该注意标准抽象开销。此外，它在当前状态下非常基于SQL Server。
  4. 如果您正在使用SQL Server，则可能是。如果您现在正在使用LINQ进行其他事情，比如在XML数据（很棒），对象数据，数据集上，那么是的，您应该切换到为所有这些内容提供统一的数据语法。就像lagerdalek提到的，如果没有问题，就不要修复它。 从快速查看.netTiers应用程序框架来看，我会说，如果您已经投资了该解决方案，则似乎可以为您提供比简单的数据访问层更多的功能，因此您应该坚持使用它。

从我的经验来看，LINQ to SQL是中小型项目的好解决方案。它是ORM，这是提高生产力的好方法。它还应该为您提供另一层抽象，使您能够更换底层层。 Visual Studio中的设计器（我相信VS Express也是如此）非常易于使用和简单。它为您提供常见的拖放和基于属性的对象映射编辑。

@ Jason Jackson - 设计器确实允许您手动添加属性，但是您需要为该属性指定属性，但是您只需要执行一次此操作，它可能比将表拖到设计器中所需的时间长3分钟，但是只有在数据库本身发生更改时才需要执行此操作。这与其他ORM并没有太大区别，但是您是正确的，他们可以使这个过程更加容易，并找到仅更改了的那些属性，甚至为此类需求实施某种重构工具。

资源：

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

2
我尝试在一个小项目中使用Linq to SQL，认为我想要快速生成一些东西。但是我在设计师中遇到了很多问题。例如，每当你需要向表中添加一个列时，你基本上必须删除并重新添加表定义。如果你已经设置了表的任何属性，那么你必须重新设置这些属性。对我来说，这真的减缓了开发过程。
LINQ to SQL本身很好。我真的很喜欢它的可扩展性。如果他们能改进设计师，我可能会再次尝试它。我认为这个框架会从更多针对像web开发这样的脱机模型的功能受益。
请查看Scott Guthrie的LINQ to SQL系列博客文章，以获取一些很好的使用示例。
一个很棒的网站，向你展示如何使用Partial Classes，在仍然能够刷新设计师生成的源文件的情况下修改LINQ到SQL生成的源文件。 http://dotnetslackers.com/articles/csharp/Making-LINQ-to-SQL-A-Bit-More-Abstract.aspx - Steve T
1

NetTiers非常适合生成重型和强大的数据访问层(DAL)，我们在核心库和框架中内部使用它。

就我所知，LINQ（在所有版本中，但特别是针对SQL）非常适用于快速数据访问，我们通常将其用于更敏捷的情况。

这两种技术都相当不灵活，需要重新生成代码或dbml层才能进行更改。

话虽如此，如果使用得当，LINQ 2 SQL是一个相当强大的解决方案，甚至由于其易用性，您可能会开始将其用于未来的开发，但我不会为此放弃您当前的DAL - 如果它没有出现问题...

0

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

所以...如果你有一个小型数据库，我会建议你使用它。如果不是，我会等待一些改进再做决定。

你的经验是如何告诉你“实际对数据库的操作会更慢”的？你应该包括你所进行的性能测试的描述，以便人们知道你不是在凭空捏造。 - liammclennan
0

我现在正在一个相当大的项目中使用LINQ to SQL（大约150个表），并且它对我来说非常有效。我以前使用的ORM是IBatis，它功能强大，但需要很多工作来完成映射。LINQ to SQL对我来说表现出色，到目前为止，开箱即用，非常容易使用。在过渡中确实存在一些差异，但我推荐使用它。

另外说明，我从未使用过或者了解NetTiers，所以我不会否定它的效果，但总体来说，LINQ to SQL已经被证明是一种极其可行的ORM。

0
我们团队过去常使用 NetTiers，并发现它确实很有用。但是...我们越用越发现它带来了许多麻烦和痛点。例如，每当你对数据库进行更改时，需要使用 CodeSmith 重新生成数据访问层(DAL)，这涉及到以下步骤：
  • 在三个独立项目中重新生成数千行代码
  • 重新生成数百个存储过程
也许还有其他方法可以做到这一点，但这就是我们必须做的。源代码重新生成还好，虽然有点可怕，但还好。真正的问题出现在存储过程上。它没有清理任何未使用的存储过程，因此如果你从模式中删除一个表并重新生成 DAL，该表的存储过程将不会被删除。此外，在处理数据库更改脚本时，这变成了一个非常头疼的问题。我们必须比较旧的数据库结构与新的数据库结构，并创建一个更新客户端安装的更改脚本。这个脚本可能包含数以万计行的SQL代码，如果执行时出现问题（而这种情况经常发生），解决起来就相当麻烦。

然后灯亮了，NHibernate作为ORM。它肯定需要一些时间来上手，但是它非常值得。有很多支持它的东西，所以如果你需要做某件事情，很可能已经有人做过了。它非常灵活，允许您控制它的每个方面，甚至更多。它也变得越来越容易使用。Fluent Nhibernate正在成为一种摆脱需要的xml映射文件的好方法，而NHibernate Profiler提供了一个优秀的界面，以查看背后发生了什么，以增加效率并消除冗余。

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

使用 netTiers，您可以将其设置为使用参数化 SQL 而不是存储过程。这样可以避免数据库中存储过程的混乱。 - Aaron Fischer
1
你好，我们正在努力消除/减少下一个版本的.netTiers（v3.0）中的这些开销和痛点。谢谢 -Blake Niemyjski - Blake Niemyjski
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接