Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
rajdaksha
Aged Yak Warrior
595 Posts |
 Posted - 2009-09-30 : 08:44:31
|
| HiBusiness logic is better to implement in FRONT END layer or BACK END database like stored procedures.We have done big discussion. What I have suggested is BACK END…Please put your valuable points…..I expect more reply from experts...thanks-------------------------R... |
|
|
smarty
Starting Member
13 Posts |
Posted - 2009-09-30 : 09:06:08
|
| The standard model is to have a business logic layer in between the "Front end" and the "Back end (database)"This article is a bit old but still useful (http://msdn.microsoft.com/en-us/library/aa581779.aspx) -----------------------------------Free SQL server monitoring for DBA'swww.realsmartsoftware.co.uk |
 |
|
|
denis_the_thief
Aged Yak Warrior
596 Posts |
Posted - 2009-09-30 : 14:23:31
|
| I really don't know the best approach but I can sit on the fence and say: it depends. And one thing it depends on is what actually is 'Business Logic'. In a sense if you are writing a Business Application, isn't all Logic, Business Logic. I've seen both so easy for me to make negative statements about both:Negative Aspects of having Business Logic in Stored Procedures:- Stored Procedures can get long and messy- Any change to business rules mean Stored Procedures must change too- Difficult to Change Database Server (i.e. such as from SQL Server to Oracle)Negative Aspects of having Business Logic outside of Stored Procedures (ie. Middle Tier/ Middle Layer):- More coding as code must be written twice, first to send or retrive data from the Database to the Business Layer, sencondly to send or retrieve data from the Business layer to the Presentation Layer- Difficult for Reporting - for example Crystal Reports work with stored procedures can can't hook up to a Business Layer- Can be Slower - complex processes that comprise of selects, inserts and updates inter-mixed with Business Logic will require several round trips to the DatabaseHere's a good article:http://thedailywtf.com/articles/the-mythical-business-layer.aspx |
|
|
|
blindman
Master Smack Fu Yak Hacker
2365 Posts |
Posted - 2009-09-30 : 16:06:10
|
| People need to stop talking about "business logic" as a single type of logic. When referring to "business logic", it is easy to point out examples that would be absurd to include in the data layer, as well as examples that do not belong in the application layer.Business logic can be "data logic" that is tied closely to the data (column datatype being the most basic example) to "interaction logic" that is tied closely to the front-end (order of processing for creating a new customer, for instance).Data logic should be implemented in the data layer.Application logic should be implemented in the application layer (or middle-tier).The question we need to answer then changes from "where should business logic be implemented?" to "what kind of business logic does this rule fall under?"________________________________________________If it is not practically useful, then it is practically useless.________________________________________________ |
|
|
|
rajdaksha
Aged Yak Warrior
595 Posts |
|
|
|
|
|
Business logic