从 ASP 迁移到存储过程中的业务逻辑
您将如何构建一个大部分业务逻辑已经在存储过程中的大型项目？
这里有一些背景知识：
我们正在从经典 ASP 迁移到 ASP.NET (VB)，几乎所有业务逻辑都在存储过程中。 摆脱那里的逻辑几乎是不可能的，因为我的老板不想这样做（太贵，花了太长时间，没有“真正的”附加值）。
我正在考虑制作一个由 aspx 页面组成的表示层，一个业务逻辑/数据访问层 基本上会获取数据并与现有的存储过程和业务实体层进行交互 将由类（实体和集合）组成，其中包含这两层之间交互的信息。
我想要创建这些层的原因是能够重用大部分代码而不重复它。
我想听听您对如何构建新应用程序的看法。
How would you structure a large project with most of the business logic already inside stored procedures?
Here is a little bit of background :
We are moving from classic ASP to ASP.NET (VB) and pretty much all the business logic is inside stored procedures.
Getting the logic out of there is pretty much impossible since my boss doesn't want to (too expensive, takes too long, no "real" added value).
I was thinking about making a presentation layer made of aspx pages, a business logic / data access layer
that would basically get the data and interact with the existing stored procedures and a business entities layer that
would be made of classes (for entities and collections) containing the information to interact between those two layers.
The reason I wanted to make those layers was to be able to reuse most of the code without duplicating it.
I would like to have your opinion on how you would structure the new application.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我将创建一个基于 Linq2SQL 或实体框架的数据访问层，您可以在其中引用/映射现有的存储过程（也是用户定义的函数）以及表。
请参阅以下内容：
I would create a data access layer based on Linq2SQL or Entity Framework, where you could reference/map your existing stored procedures (also user defined functions) as well as your tables.
See these:
那么你的想法是完全正确的..业务逻辑不应该在存储过程中..我不是业余爱好者，我在开发方面拥有丰富的经验，现在我正在开发一个项目，该项目的所有业务逻辑都在SP中，甚至超过1000行还有动态sql查询，相信我，我向任何一个天才提出挑战，你不能调试SP的SP中的单行更改是痛苦的，它消耗大量时间来理解效果和更改。
最好将 DAL 与 SP 分开
well your idea is prefectly right ..Business logic should not be in Store procedure.. i am not amteur i m have vast experience in development and now i m working on project which have all business logic in SP' even more then 1000 lines are there and also dynamic sql queries are there and belive me i challenge to any one genius that you cant debug the SP's A single line change in sp's is pain and it consume lot ot time to understand the effect and change.
well better DAL seprate from SP
请注意不要过度热衷于“从存储过程中获取逻辑”。存储过程在许多应用程序中都发挥着重要作用。如果明智地使用，它们通常是封装某些逻辑的最佳位置。关于存储过程的使用的一个很好的答案 - Use of StoredProcs in an application
在.NET 方面，您的设计听起来很合理。您的 DAL 可以环绕存储过程层并抽象业务对象的持久性。如果您仍然需要单独的“业务逻辑”层，那么它应该与 DAL 分开。
对于前端，您可能需要考虑 ASP.NET MVC 而不是 ASP.NET Webform。 MVC 是一种更自然地适合基于网页的应用程序的模式，并且通常是经典 ASP 站点更容易迁移的目标。
Be careful not to be over enthusiatic about "getting the logic out of" the stored procedures. Stored procedures have a valid role in the many applications. If used wisely, they are often the best place for encapsulating certain logic. A good answer regarding the use of stored procedures - Use of StoredProcs in an application
On the .NET side, your design sounds reasonable. Your DAL can wrap around the stored procedure layer and abstract the persistence of your business objects. If you still require a seperate 'business logic' layer then this ought to be seperate from the DAL.
For the front end, you may want to consider ASP.NET MVC rather than ASP.NET webforms. MVC is a pattern which fits far more naturally with a web page based application and is often an easier migration target for classic ASP sites.
将业务逻辑与数据访问代码分开是一个好主意......特别是如果它位于存储过程中。然而，问题是你的老板可能与你意见不一致。他认为只需将 asp 代码移至 asp.net 即可，无需修改后端。重新构建系统将是昂贵且耗时的……并且很可能会引入错误等。
第一步是尝试说服您的老板，做这样的事情是有价值的。
It's a good idea to separate out the business logic from the data access code...especially if it is in the stored procedures. The problem, however, is that your boss probably does not see eye to eye with you. He sees just moving the asp code into asp.net without modifying the back end. It is going to be expensive and time consuming to rearchitect the system...and there is a lot of potential for introducing bugs, etc.
The first step is trying to convince your boss that there is value in doing something like this.