8

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

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

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

4

6 回答 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以在多核机器上实现更高的性能。

于 2008-10-08T22:12:05.080 回答
2

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

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

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

于 2008-09-30T19:18:54.950 回答
1

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

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

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

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

于 2008-09-17T09:20:43.533 回答
0

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

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

于 2008-09-17T09:42:27.087 回答
0

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

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

于 2008-09-30T19:25:27.367 回答
0

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

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

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

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

Moving from NetTiers to NHibernate has been painful, but in a good way. It has forced us to move into a better architecture and re-evaluate functional needs. NetTiers provided tons of data access code, get this entity by its id, get this other entity by its foreign key, get a tlist and vlist of this and that, but most of it was unnecessary and unused. NHibernate with a generic repository and custom repositories only where needed reduced tons of unused code and really increased readability and reliability.

于 2009-04-28T02:27:13.653 回答