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

发布时间：2020-12-15 08:37:39 所属栏目：Java 来源：网络整理

导读：我工作的公司开发了一个大型应用程序,几乎完全基于存储过程. 我们使用经典ASP和SQL Server,业务逻辑的主要部分包含在这些存储过程中. 例如,(我知道,这很糟糕……)单个存储过程可以用于不同的目的(插入,更新,删除,进行一些计算……).大多数情况下,存储过程用

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

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

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

我们计划在不久的将来转向ASP.NET(WebForms).

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

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

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

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

在我看来

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

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

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

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

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!