混合存储过程业务逻辑和ORM

Question

我工作的公司开发了一个大型应用程序，几乎完全基于存储过程。

我们使用经典ASP和SQL Server，业务逻辑的主要部分包含在这些存储过程中。

例如，（我知道，这很糟糕......）单个存储过程可以用于不同的目的（插入，更新，删除，进行一些计算......）。 大多数情况下，存储过程用于相关表的操作，但情况并非总是如此。

我们计划在不久的将来转向ASP.NET（WebForms）。

我已经在StackOverflow上阅读了很多帖子，建议我将业务逻辑移到数据库之外。 问题是，我试图说服那些在我们公司做出决定的人， 我无法改变他们的想法 。

由于我希望能够使用面向对象编程的优点，我想将表映射到实际的类。 到目前为止，我的解决方案是使用ORM（实体框架4或nHibernate）来避免手动映射对象（主要是检索数据）并使用某种数据访问层来调用现有的存储过程（用于保存）。

我想要你的建议。 你认为这是一个很好的解决方案吗？ 有任何想法吗？

编辑：我应该采用标准的DataTable / DataRow方法吗？

Answer 1

在我看来

出于多种原因，存储过程是您的朋友。 我强制在我的项目中执行存储过程中的所有数据库操作，并锁定SQL服务器上的应用程序帐户，只允许它执行存储过程（没有任何类型的直接表访问）。 尽管如此，在同一个proc中混合更新/删除操作对我来说是不好的做法（尽管我倾向于在同一过程中组合插入/更新）。

另请注意：当您从ASP迁移到ASP.NET时，存储过程中的任何逻辑都不必重新实现，因为它存在于Web代码之外。 +100点用于保持查询属于他们的位置。

这些天常见的“智慧”表明你应该只使用你的数据库服务器作为对象存储，我强烈反对。 我有几个项目，经过多年的服务，突然需要与其他用不同语言编写的应用程序共享数据和逻辑。 将大多数db代码实际存储在数据库中以及应用程序代码之外，这使得项目之间的代码重复变得非常简单和最小化。

将ORM与存储过程混合听起来像是一个在年轻时减肥和头发的好方法。

将现有应用程序从当前数据模型切换到ORM，除了从ASP迁移到ASP.NET MVC的复杂性之外，还为已经具有挑战性的任务添加了许多变量和失败点。 如果你不能向权力提出一个令人信服的论点，那就是ORM是一个好主意，你可能会问自己为什么会这样。

Answer 2

我认为这是一个很好的解决方案。 如果您不仔细检查可能对表数据执行的操作，请注意可能产生的副作用。

另一方面，对于某种应用程序，我仍然认为在数据库端拥有业务逻辑是一个非常好的解决方案。 从数据库中取出并不总是最佳选择。 有很多事情需要考虑。

Answer 3

您期望获得的面向对象编程有哪些优势？

当人们谈论OOP的优势时，他们通常意味着集中业务逻辑或围绕相关操作和数据构建有意义的抽象。 将业务逻辑放在存储过程中会破坏这些抽象并分散业务逻辑。

如果您的团队打算保留业务逻辑程序，您至少应该考虑保持这种方式：使代码程序化，以便只有一个地方可以查找您的逻辑。

话虽如此，使用ORM将数据映射到您的网站中使用的数据传输对象 （没有任何重要的行为或逻辑）是很常见的。 Dino Esposito的数据传输对象的优点和缺点很好地解决了您的问题 - 只需将您的存储过程视为服务层。

Answer 4

这完全取决于业务需求。 存储过程中有多少业务逻辑，以及多个存储过程之间建立业务工作流程的依赖关系很重要。

可扩展性受到很大影响。 在进程等待完成时，依赖逻辑可以阻止CPU使用。 并行化对于服务驱动的体系结构非常重要，其中数据库需要基本上是读取缓存以提高性能。 为什么要击败一个CPU盒并阻塞并堵塞可以分配的工作流程？

我认为这些论点必须考虑到这些因素而不会在任何年龄都失去头发。