代码侧或存储过程中的业务逻辑? [英] Business logic in code side or in stored procedure?

问题描述

HI再一次，

在我们公司中，我们正在处理大型ERP和薪资系统.如今，我们有一种争论，即将在vb.net中的另一个类中包含业务逻辑，或者应该在SQL方面.

我相信这部分是关于数据库的，因此所有业务逻辑都应放在存储过程和sql函数中，我的其他伴侣都说，所有内容都应该在vb类中.

现在，在这种情况下，我认为我们需要您的建议.因此，请对此提供建议.

祝你有美好的一天... !!!

HI All once again,

In our company we are dealing with big ERPs and Payroll systems. Now a days we have an argument about to have a business logic in a different class in vb.net or it should be in a SQL side.

I believe this part is all about database so all the business logic should go to stored procedures and sql functions where my other mates say that everything should be in a vb class.

Now in this situation I think we need your suggestions. So please advice on this.

Have a nice day...!!!

推荐答案

这是一次很棒的辩论/对话，我本人也参与其中.我可以坦白地说，我认为没有正确"或错误"(好的，也许有，但是请允许我在这里放一点个人电脑，以免从一开始就冒犯那些DB专家)，但只有每种方法的优点"和缺点".我认为两者都有其优点和缺点，除非表面上有一种明显的性能优势，否则没有任何选择可以作为表面上的明显选择.但是，我对论点的一面有偏见，下面将详细介绍.

设计应用程序时的默认立场应该是业务逻辑保存在应用程序代码中，而不是数据库存储过程中.仅在需要性能时将业务逻辑移到StoredProcedures中.

我认为，StoredProcedures应该仅用于许多不同应用程序和/或语言所需的某些操作.如果许多不同的应用程序具有或将具有相同的需求，请考虑将其分解为存储过程.您无法轻易使用应用程序代码执行此操作，因为不同的语言需要自己重新编码.

http://c2.com/cgi/wiki?BusinessLogicInStoredProcedures

This is a great debate/conversation, and I have been a part of it several times myself as well. I can honestly say there is no ''right'' or ''wrong'' in my opinion (OK maybe there is but let me be a little PC here as to not to offend those DB folks right from the start), but only ''pros'' and ''cons'' to each method. I think both have their advantages and disadvantages, and no option really screams out as the obvious choice on the surface unless there is say some significant performance advantage one way or the other. However I have my bias on 1 side of the argument as I will detail below.

The default stance in designing an application should be that business logic is held in the application code, NOT in database stored procedures. Only move business logic into StoredProcedures as performance needs required.

In my opinion, StoredProcedures should only be used for some operation that many different applications and/or languages need. If many different apps have or will have the same need, then consider factoring it to a stored procedure. You can''t readily do this with app code because different languages would need re-coding for themselves.

http://allen-conway-dotnet.blogspot.in/2012/02/should-i-place-my-business-logic-in.html

http://c2.com/cgi/wiki?BusinessLogicInStoredProcedures

这只是我的意见:

业务逻辑应该位于业务逻辑层"中，但是一个类似乎很荒谬，您应该根据应用程序的大小来拥有一个完整的BL项目.

每当我有了业务逻辑时，我都会把它放在那儿，所以我知道，即使是2年后，它也应该在那里，只有在那里，这就是BL最终存在的原因，所以...

但是该规则也有例外，最重要的是性能.如果要通过在其中而不是在数据库中放置一些业务逻辑来严重地降低性能，则可以考虑创建一个异常，但是作为任何异常，它都应保持为异常.

正如我所说的，这就是我的做法，我可能完全错了.

希望对您有所帮助.



您通常会遇到这样的事情:

UI(用户界面)-> BL(业务逻辑层)-> DAL(数据访问层)-> SP(存储过程，这是可选的)

顾名思义，业务逻辑层用于...业务逻辑:)
这是一个三层体系结构.

[/Edit]

Hi,

This is just my opinion:

Business logic should be in the "Business Logic Layer", a single class seems ridiculous though, you should have an entire BL project(s) depending on the size of your application.

Whenever I have Business Logic I put it there, so I know, even 2 years later, that it should be there and only there, that''s why the BL exists in the end so...

But there are exceptions to that rule, the most important is performance. If you are critically loosing performance by putting some business logic there instead than on the database, then you might consider making an exception, but as any exception it should remain an exception.

As I said, that''s just how I do it, I may be totally wrong.

Hope it helps.



You would usually have something like this:

UI (User Interface) -> BL (Business Logic Layer) -> DAL (Data Access Layer) -> SP (Stored Procedures, this is optionnal)

As it''s name says, the Business Logic Layer is for... Business Logic :)
This is a three tier architecture.

[/Edit]

我认为数据层即应包含详尽的数据访问过程.数据层顶部的数据访问层应提供特定于应用程序的数据访问逻辑.并且数据访问层顶部的业务逻辑层应包含业务特定的逻辑.

想象一下2种情况1，其中未对数据访问层进行编码并且使用了ORM，则业务特定逻辑将位于BLL中(也许使用linq).第二种情况是需要更改基础数据技术(例如sqlserver到mysql)，然后您不必重写应用专用逻辑，因为它仍在BLL中.

I think the data layer i.e. should contain the procedures for exhaustive data access. The Data access layer on top of data layer should provide the applcation specific data access logic. and the Business logic layer on top of Data access layer should contain business specific logic.

Imagine 2 scenarios 1, where Data access layer is not coded and an ORM is used then the business specific logic will be in BLL (perhaps using linq). second scenario is where underlying data technology needs to be changed (like sqlserver to mysql) then you dont have to rewrite applicatin specific logic since it is still in BLL.

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