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

Question

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

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

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

我们计划在不久的将来迁移到 ASP.NET (WebForms)。

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

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

我需要你的建议。 你认为这是一个好的解决方案吗？有什么想法吗？

编辑:我应该只使用标准的 DataTable/DataRow 方法吗？

Answer 1

在我看来

出于很多很多原因，存储过程是您的 friend 。我强制在项目的存储过程中执行所有数据库操作，并锁定应用程序在 SQL 服务器上的帐户，只允许它执行存储过程(不能直接访问任何类型的表)。尽管如此，在同一个过程中混合更新/删除仍然让我觉得是一种糟糕的做法(尽管我倾向于在同一个过程中组合插入/更新)。

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

如今，普遍的“智慧”表明您应该只将数据库服务器用作对象存储，我强烈反对这一观点。我有几个项目，在服务多年后，突然需要与其他用不同语言编写的应用程序共享数据和逻辑。将大部分数据库代码实际放在数据库中，并在应用程序代码之外，这使得项目之间的代码重复变得非常简单和最小化。

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

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