从ASP迁移，业务逻辑陷入存储过程

Question

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

以下是一些背景知识：

我们正在从经典的ASP转向ASP.NET（VB），几乎所有的业务逻辑都在存储过程中。 由于我的老板不想（过于昂贵，需要太长时间，没有“真正的”附加价值），因此将逻辑排除在外几乎是不可能的。

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

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

我想就如何构建新应用程序发表意见。

Answer 1

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

见这些：

• How to: Define a Model with a Stored Procedure
• Stored Procedures (LINQ to SQL)

Answer 2

你的想法是完全正确的..商业逻辑不应该在商店程序中..我不是业余的我有丰富的开发经验，现在我正在研究SP中所有业务逻辑的项目甚至超过1000行在那里，还有动态的SQL查询，并且相信我，我挑战任何一个你无法调试SP的天才sp的单行更改是痛苦的，它消耗了很多时间来理解效果和变化。

更好的DAL分离SP

Answer 3

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

第一步是试图说服你的老板做这样的事情是有价值的。

Answer 4

小心不要过于热衷于“从存储过程中获取逻辑”。存储过程在许多应用程序中都有有效的作用。如果明智地使用它们，它们通常是封装某些逻辑的最佳位置。关于使用存储过程的一个很好的答案 - Use of StoredProcs in an application

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

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