存储过程中的业务逻辑是/否 [英] Business Logic in Stored Procedure Yes / No

问题描述

关于-是否将业务逻辑放入存储过程?"这一主题一直存在争议.如果我们决定不使用ORM工具并且不将业务逻辑放入存储过程中，那么我们将业务逻辑放在哪里?

在以前的应用程序中，我始终倾向于仅将所有业务逻辑放入存储过程中.然后从.NET代码中，我使用数据访问应用程序块来调用这些存储过程. SQLHelper等.但这并非一直都是这种情况.所以我做了一些谷歌搜索，但最终陷入了混乱.......

有什么建议吗...?

问候，
Pravin

Hi,

There is always a debate over the topic - "Whether to put the business logic in Stored Procedure or Not?". If we decide not to use the ORM Tool and not to put the Business Logic in Stored Procedure then where would we put the Business Logic?

In my previous applications I have always preferred putting all of the Business Logic in Stored Procedures only. Then from .NET code I call these Stored Procedures using Data Access Application Blocks. SQLHelper etc. But this can not be the scenario all the time. So I did some googling but ended up in confusion.......

Any suggestionss...?

Regards,
Pravin

推荐答案

恕我直言，有一个原因使您拥有数据访问层和业务逻辑层.如果您有一个没有太多业务逻辑的小型应用程序，那么我想您可以将其放在您的SP上.但是，如果您有复杂的应用程序，建议您为此创建一个BLL.原因是可维护性.如果有待处理的任务要对它们进行一些与数据相关的修复/增强，该怎么办?很有可能，每次发生这种情况，您最终都可能会修改SP的业务逻辑部分.

IMHO, there''s a reason why you have a Data Access Layer, and a Business Logic Layer. If you have a small application that does not have much business logic, then I guess you can at put it on your SP. But when you have a complex app, I suggest you create a BLL for that. Reason for it is maintainability. What if there are pending tasks to make some data related fix/enhancement to them? Chances are, you might end up modifying the business logic part of the SP every time this happens.

这篇关于存储过程中的业务逻辑是/否的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！