从 ASP 开始，业务逻辑被困在存储过程中答案

【问题标题】：Moving from ASP, business logic trapped inside stored procedures从 ASP 开始，业务逻辑被困在存储过程中
【发布时间】：2011-05-01 22:10:18
【问题描述】：

如果大部分业务逻辑已经在存储过程中，您将如何构建一个大型项目？

这里有一点背景：

我们正在从经典的 ASP 转移到 ASP.NET (VB)，几乎所有的业务逻辑都在存储过程中。因为我的老板不想（太贵，需要太长时间，没有“真正的”附加值），所以从那里找出逻辑几乎是不可能的。

我正在考虑制作一个由 aspx 页面组成的表示层，一个业务逻辑/数据访问层这基本上会获取数据并与现有的存储过程和业务实体层进行交互将由包含在这两个层之间交互的信息的类（用于实体和集合）组成。

我想要制作这些层的原因是能够重用大部分代码而不复制它。

我想听听您对如何构建新应用程序的意见。

【问题讨论】：

【解决方案1】：

将业务逻辑与数据访问代码分开是个好主意……尤其是在存储过程中时。然而，问题是你的老板可能与你意见不一致。他认为只是将 asp 代码移动到 asp.net 中而无需修改后端。重新构建系统将是昂贵且耗时的......并且有很多潜在的引入错误等。

第一步是试图让你的老板相信做这样的事情是有价值的。

【讨论】：

【解决方案2】：

注意不要过于热衷于“从存储过程中获取逻辑”。存储过程在许多应用程序中都发挥着重要作用。如果使用得当，它们通常是封装某些逻辑的最佳位置。关于使用存储过程的一个很好的答案 - Use of StoredProcs in an application

在 .NET 方面，您的设计听起来很合理。您的 DAL 可以包裹存储过程层并抽象出业务对象的持久性。如果您仍然需要单独的“业务逻辑”层，那么它应该与 DAL 分开。

对于前端，您可能需要考虑 ASP.NET MVC 而不是 ASP.NET webforms。 MVC 是一种更自然地适合基于网页的应用程序的模式，并且通常是经典 ASP 网站更容易迁移的目标。

【讨论】：

【解决方案3】：

我将创建一个基于 Linq2SQL 或实体框架的数据访问层，您可以在其中引用/映射您现有的存储过程（也是用户定义的函数）以及您的表。

查看这些：

【讨论】：

【解决方案4】：

你的想法完全正确..业务逻辑不应该在存储过程中..我不是业余爱好者，我在开发方面拥有丰富的经验，现在我正在从事在 SP 中包含所有业务逻辑的项目，甚至超过 1000 行那里还有动态 sql 查询，相信我，我向任何一个天才挑战，你不能调试 SP

更好的 DAL 与 SP 分离

【讨论】：