1

我即将着手重写 .NET 3.5sp1 中的 VB6 应用程序。VB6 应用程序编写得非常好，数据层完全基于存储过程。我想使用像 Linq2SQL/Entity Framework/NHibernate/SubSonic 这样的自动化工具。诚然，除了一次性项目，我没有在任何其他项目中使用过这些工具。

我担心所有这些选择可能遇到的潜在问题是速度。例如，现在要检索单行（或整个列表），我使用以下存储过程：

ALTER PROCEDURE [dbo].[lst_Customers]
 @intID     INT = NULL
,@chvName   VARCHAR(100) = NULL
AS

SELECT   Customer_id, Name
FROM dbo.Customer
WHERE (@intID IS NULL OR @intID = Customer_id)
 AND (@chvName IS NULL OR Name like ('%' + @chvName + '%'))
ORDER BY name

要在 Linq2SQL/Entity Framework/NHibernate/SubSonic 中检索单行，这些解决方案是否必须将整个列表带到客户端并找到我需要的行？

那么，对于大数据域的应用，数据访问策略的共识是什么呢？

4

6 回答 6

6

我将扮演魔鬼的拥护者，并建议您至少考虑坚持使用存储过程。这些代表您不必重新编写和调试的代码块。 这篇来自我们的 Very Own [tm] Joel Spolsky 的文章给出了避免完全重写的连贯论证。

给定一个“绿地”项目，您可以使用您想要的东西，而 O/R 映射器可能是一个不错的选择。但是，您已经说过 VB6 应用程序编写得很好。如果存储过程写得很好，那么您可以免费获得一些应用程序并且它已经调试过了，而且您可以回收数据库模式并避免数据迁移带来的大部分痛苦。

Fowler 的企业应用程序体系结构模式应该为您提供一些很好的指导，帮助您设计一个数据访问层，该层可以很好地与存储过程配合使用，而不会引起维护问题。

这在 Oracle/Java 应用程序上很常见。许多旧版 Oracle 应用程序在 PL/SQL 中拥有大量存储过程代码——这是 Oracle Forms 客户端-服务器时代的标准架构。在 Java 中为存储过程编写包装器并在包装器之上构建用户界面是常见的做法。

其他海报之一提到 Subsonic 可以为存储过程生成包装器。

曾几何时，我有机会做一个数据字典破解，它为 PL/SQL 存储过程生成了一个概念验证 Java/JDBC 包装器——IIRC 只花了一天左右的时间。鉴于这并不难做到，我会惊讶地发现，在你可以从现成的东西上做这件事的时候，没有多少选择。在紧要关头，自己编写也不是那么难。

于 2008-11-12T20:06:42.343 回答
2

我不会谈论 Linq-to-SQL、实体框架或 NHibernate，但我爱上了 SubSonic。我的经验是非常积极的。

通常，这些工具的工作方式是，它们在托管代码中为您构建参数化查询，将该访问封装在类中，然后将这些类公开给您的应用程序。完全生成的 DAL 摇滚。

通过使用参数化查询，您对他们可能“必须将整个列表带到客户端并找到我需要的行”的担忧得到了处理。它们支持where子句和其他过滤以获取您需要的行。您可以执行 的等效操作select * from foo，但您不会陷入该模式。

也就是说，SubSonic 确实——当直接用于直接表/视图访问时——会降低整行，这在某些情况下可能是不利的。但是，您通过存储过程的访问不是问题——我无法与其他人交谈，但 SubSonic 有助于创建一个SPs封装所有过程的类，允许您将它们作为方法调用，并返回适当DataTable的 s，您可以然后根据需要手动解析。还有一些方法可以从 procs 初始化 DAL 类列表，因此如果 proc 返回一个直接匹配表/视图的数据集，您仍然可以拥有更清晰的语法，而无需手动处理。

（顺便说一下，SubSonic 治愈了我的“所有事情的 procs”。我现在通常几乎没有像过去那样花时间做 CRUD procs，只是最终将它们用于复杂的报告。但是你的里程可能，实际上会有所不同。）

于 2008-11-12T19:24:37.797 回答
1

我建议使用 SubSonic 生成所有代码来访问您现有的存储过程，这样可以减少由于新的数据访问层而导致回归的机会。然后可以通过使用 SubSonic 生成的 ActiveRecord 类访问任何新功能。在我看来，这似乎是最安全和最快的方法，

我不同意 NHibernate 的建议，因为它不太适合使用存储过程。

于 2008-11-12T19:35:17.633 回答
1

我们尝试将实体框架用作 orm，但在尝试将其与域驱动开发一起使用时遇到了多个问题。Linq to Sql 也有一些限制，我相信微软将在下一个版本中停止支持它。

于 2008-11-12T20:25:47.907 回答
1

如果查询在存储过程中，那么它们很有可能已经得到了很好的优化。并且可能他们对 JOINS、子查询等自由使用 SQL 表达式。

使用 ORM 类型的抽象层准确地复制这种效率和表现力将是一个挑战 - 特别是如果您不完全熟悉这些工具。

在直接了解应用程序的其余部分后，您始终可以重构查询。ORM 世界的变化太快了，当你到达那里时，选择肯定会有所不同。

于 2008-11-12T20:55:50.733 回答
0

甚至根据作者之一 Rob Connery 的说法，SubSonic 的编写更多是为了支持快速应用程序开发，而不是关于大型应用程序。我会说选择 NHibernate，因为您会从社区中找到最多的支持以及久经考验的真正测试框架。您可以从 www.dimecasts.net 获得有关设置 NHibernate 东西的良好信息。

于 2008-11-12T19:31:00.577 回答