DEFINITION
Business logic refers to the business rules that are in fact the core business functionality services an application provides. A definition adapted after Shepker [13] can be :
Business logic, also called sometimes business rules, is the application code that drives using in following the processes that compose the business work. What is very important is that how and what type of data is stored in the database tables is part of the business rules , conceptually speaking.
Where the business rules should reside in an application ?
There are maybe as many opinions as speakers on this issue, but two main directions can be identified. Shepker again in his book [13] names the two approaches as following : the no business logic camp which is the way of building applications by placing almost all the code in the client. The database tier is just used for storing data and nothing more than this. The extremists sustainers of this approach say that even the referential integrity should be the task of the application objects.
The consequence of applying this school of thought is the so-called fat client , which has the disadvantage that even the most minor change in the code needs recompiling. This would not pose so much of a problem for isolated cases, but just imagine the scenario of a large client company like a bank, with hundreds of terminals, spread across couple of countries. It results a very cost prohibitive picture. The advantage identified and invoked by the sustainers are presented also by Fowler [14] in his work. The main benefit arises from the speed gain. It has been proved that the triggers and stored procedures overhead can lead to poor performance under certain conditions of heavy workload.
On the other hand , the disadvantages of having fat clients with no business encapsulated into the database layer lead developers to migrate towards an alternative idea : placing all the business rules constraints, processes and threads ( units ) of work inside the database layer, explicitly in stored procedures.
Shepker named this second alternative the all business logic camp and its main advantages are that any minor or major changes in the business rules can be done easily and without affecting the code in the client application. Also the memory resources needed by the application are less prohibitive in this situation.
Anytime there is an advantage, there has to be a disadvantage as well. One disadvantage we have mentioned earlier, and it refers to the portability of the code. For example in order to move an application from one RDMS to another, let's take SQL Server and Oracle, the code looks similar but it needs to be rewritten entirely in order to get it work.
Another aspect is that Transact SQL is not so powerful like other programming languages, C# for example. It can be difficult to resolve problems that can easily be done at the client's application site. But the argument holds for some situations in the favor of the fat clients sustainers, while in other situations the database specialists ask the Java or C programmers to leave the SQL and stick to their procedural or object oriented languages. And they are right from the point of view of unlocking database performance : "set-based" mentality.
FINDING MIDDLE GROUND and CONCLUSIONS
Lhotka [15] and Fowler [14] bring the issue under discussion to a reasonable compromise. The right solution depends on the skills of the developers. If you have a less-than-expert person writing your business logic in TSQL you\'ll often get worse performance than if you had the IO from another machine. Misuse of temp tables and a host of other issues can hurt the application, but well written stored procedures have widely accepted benefits.
To draw a conclusion, we'll implement our application with as many business rules in the database layer in the form of stored procedures that encapsulate data retrieval and update and triggers that provide referential integrity, up to some point though. The literature shows that there are benefits of having business in the application objects as well, and finding the right proportion is the task we assume.
