Business logic in code side or in stored procedure?

Question

0.00/5 (No votes)

See more:

SQL-Server-2005

, +

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...!!!

Posted 27-Mar-12 5:29am

hiren soni

Add a Solution

Comments

Muralikrishna8811 27-Mar-12 11:37am

Hi,

As per my Exp ...

Based on that Logic we need place it either SP or Component(class).

If logic has feasibility to develop in SP (Sql ) then we can place it in SP
some Logic has based on external entities so obviously we go for Component.

Finally Logic place is not important ...

That Logic must have certain features like feasibility ,re-usability,upgradabilty ....

3 solutions

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Liju Sankar · Answer 1 · 2012-03-28T05:06:00

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

_Zorro_ · Answer 2 · 2012-03-27T05:36:00

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.

[Edit]

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]

Rahul Rajat Singh · Answer 3 · 2012-03-27T05:37:00

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.

Business logic in code side or in stored procedure?

3 solutions

Solution 3

Solution 1

Solution 2

Add your solution here

Preview 0