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

• 还有其他人从NetTiers到LINQ To SQL吗？
• 这是好事还是坏事？
• 有什么需要我注意的吗？
• 我们会推荐此开关吗？

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

解决方案

回答

NetTiers对于生成沉重而强大的DAL非常有用，我们在内部将其用于核心库和框架。

正如我所看到的，LINQ(所有形式，但特别是我认为我们要使用SQL的方法)对于快速访问数据非常有用，我们通常将其用于更敏捷的情况。

两种技术在不重新生成代码或者dbml层的情况下都很难改变。

话虽这么说，但是正确使用LINQ 2 SQL是一个非常强大的解决方案，由于它的易用性，我们甚至可能会开始将其用于未来的开发，但是如果它没有崩溃，我不会丢掉我们当前的DAL。 。

回答

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

所以...如果数据库很小，我会说继续。如果没有，我将等待一些改进，然后再进行更改

回答

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

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

查看Scott Guthrie的LINQ to SQL系列博客文章，以获取有关如何使用它的出色示例。

回答

我现在在相当大的项目(约150个表)上使用LINQ to SQL，它对我来说非常好。我使用的最后一个ORM是IBatis，它运作良好，但是花了很多功夫才能完成映射。 LINQ to SQL对我来说表现非常好，到目前为止，事实证明它非常易于使用。在过渡过程中肯定要克服一些差异，但是我建议使用它。

旁注，我从未使用或者阅读过NetTiers，所以我不会低估NetTiers的有效性，但是从总体上来说，LINQ to SQL已被证明是一种极为可行的ORM。

回答

• 不
• 参见＃1
• 我们应该注意标准的抽象开销。同样，它是基于SQL Server的当前状态。
• 我们是否正在使用SQL Server？如果我们现在将LINQ用于其他方面，例如XML数据(大型)，对象数据，数据集，则可以，我们应该切换为所有这些都具有统一的数据语法。就像lagerdalek提到的那样，如果它没有破裂，就不要修复它。快速浏览.netTiers应用程序框架，我想说的是，如果我们已经对该解决方案进行了投资，那么它似乎将为我们提供比简单的数据访问层更多的东西，并且我们应该坚持使用它。

根据我的经验，LINQ to SQL是中小型项目的一个很好的解决方案。这是一个ORM，它是提高生产率的好方法。它还应为我们提供另一个抽象层，该抽象层将使我们可以将其下的另一层更改为其他层。 Visual Studio中的设计器(我也相信VS Express)非常易于使用。它为我们提供了对象映射的常规拖放和基于属性的编辑。

@ Jason Hymanson Designer确实允许我们手动添加属性，但是我们需要指定该属性的属性，但是只需执行一次，它可能要比将表最初拖到Designer中的时间长3分钟，但是数据库本身每次更改只需要一次。这与其他ORM并没有太大区别，但是我们正确地认为它们可以使此操作变得更加容易，并且仅查找那些已更改的属性，甚至可以实现针对此类需求的某种重构工具。

资源：

• 为什么要使用LINQ to SQL？
• Scott Guthrie在LINQ to SQL上
• 改善LINQ to SQL应用程序性能的10条技巧
• LINQ To SQL和Visual Studio 2008性能更新
• LINQ与SQL / ADO / C＃的性能比较
• LINQ to SQL 5分钟概述

请注意，正在开发Parallel LINQ，以在多核计算机上提供更高的性能。

回答

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

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

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

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

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