大型应用程序的数据访问策略是什么

StackOverflow https://stackoverflow.com/questions/284889

题

我即将开始在 .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 中的单行，这些解决方案是否必须将整个列表传送给客户端并找到我需要的行？

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

有帮助吗？

解决方案

我将唱反调并建议您至少考虑坚持使用存储过程。这些代表了您不必重新编写和调试的代码块。 本文 来自我们的 Very Own [tm] Joel Spolsky 给出了避免完全重写的连贯论点。

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

福勒的 企业应用架构模式 应该为您提供一些设计数据访问层的良好指导，该数据访问层可以与存储过程很好地配合，而不会引起维护问题。

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

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

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

其他提示

我不能谈论Linq-to-SQL，Entity Framework，也不能说NHibernate，但我爱上了SubSonic。我对它的体验非常积极。

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

通过使用参数化查询，您担心他们可能“必须将整个列表下载到客户端并找到我需要的行”。被处理。它们支持 where 子句和其他过滤以获得您需要的行。你可以做相当于 select * from foo ，但你不会陷入那种模式。

也就是说，SubSonic确实 - 在开箱即用于直接表/视图访问时 - 关闭整行，在某些情况下可能是一个缺点。但是，通过存储过程进行访问不是问题 - 我无法与其他人交谈，但SubSonic有助于创建一个 SPs 类，封装所有过程，允许您将它们称为方法，并且返回相应的 DataTable ，然后您可以根据需要手动解析。还有一些方法可以从procs初始化DAL类列表，因此如果proc返回一个直接匹配表/视图的数据集，你仍然可以使用更清晰的语法，而无需手动处理。

顺便说一句，（顺便说一句，SubSonic让我理解了“触发所有事情的过程。”我现在通常几乎没有时间像过去那样花时间进行CRUD触发，并且最终只能使用它们进行复杂的报告。但是你的里程可能会，实际上会有所不同。）

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

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

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

如果查询在存储过程中，那么他们很可能已经进行了优化。并且他们可能会为JOINS，子查询等自由使用SQL表达式。

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

您可以在完成应用程序的其余部分之后始终重构查询。 ORM世界变化得足够快，当你到达那里时，选项肯定会有所不同。

SubSonic，即使是作者之一的Rob Connery，也写得更多，以支持快速应用程序开发，而不是大型应用程序。我会说NHibernate，因为你会从社区中找到最多的支持，以及经过验证的真实测试框架。您可以从www.dimecasts.net获取有关设置NHibernate内容的详细信息。

许可以下： CC-BY-SA 和 归因
不隶属于 StackOverflow
scroll top