When designing a typical enterprise application using a JEE stack, that is backed by a relational database, the question often arises: Should we be placing business logic in the middle tier or in database stored procedures.
Like anything else, there are trade-offs in both approaches. And like anything else, the answer lies somewhere in the middle.
However, it’s important to understand the reasons and trade-offs. Here’s my attempt to dig a bit deeper into this (relatively ancient) debate.
A brief history
Stored procedures were tremendously popular in the client-server days. They provided a means to consolidate business logic and were a logical place for all “clients” to access that logic. In that scenario, it was a no-brainer to understand that they out-performed similar logic coded on the client by making network trips for the next iteration of data. Then came the concept of an application server that was pushed by companies like BEA, IBM and later by open-source projects like apache jakarta. Moving business logic to an object oriented middle tier made sense. However around that same time JEE suffered the effects of an experiment gone wrong; namely EJB 2.1. The middle tier started being called the muddle-tier because of the associated FUD factor. ORM Frameworks like EJB-CMP, Toplink and Hibernate emerged. As first generation ORM solutions they too could not compete with the well established stored procedure.
But then Spring and Hibernate 3.3 came on the scene breathed a fresh lease of life into the aging JEE stack that was rapidly acquiring the infamous “legacy status”.
Not to be left behind, Oracle and other db heavy hitters, enhanced their stored procedure offerings by introducing dynamic data structures, cached SQL and overall improved performance.
A Common Myth
The advantage of using a stored procedure is that it allows SQL to become procedural. Combine that with the fact that it executes close to the data store, we can see why it performs well. However, there’s a common myth that the SQL statement itself will perform better(faster) if executed within the context of a stored procedure which is not true at all. We must separate the procedural processing that surrounds the SQL from the execution of the SQL statement itself.
With that background I will try to make a case for why it makes sense to having an intent to code behavior in the middle tier as against the database.
Performance:
In a multi-tier aplication, performance needs a bit of redefinition. It can no longer be defined as the time it takes for a set of rows to be returned by a SQL query. Instead, it may make sense to define it as the time it takes from when the user makes a request to when results show up on her web page (say). This metric has to consider network hops and caching in both the database and the application tiers and query performance.
In the picture above we see one key point with an ORM solution. There is caching in the middle tier too, which is absent if only stored procedures are used. What that means is better performance because of one less network hop to the database tier. In the context of the point I made above, that of separating the execution of the SQL statement with the procedural logic that surrounds it, we can see that it is conceivable that that procedural logic can be executed on data that is cached in the middle tier. This scenario can play out in a three tier configuration and avoid a round trip to the database.
Modularity and reuse
There is no doubt that code written in PL/SQL, T-SQL and the like can be made modular and certainly re-usable. However, there are certain “niceties” that an Object Oriented environment gives us which seems a bit clunky in the world of Stored Procedures. Modularity and reuse enablers such as Separation of Concerns, Coding to Interfaces and Inversion of Control, are almost always used in the context of an OO eco system. OTOH, discussions that surround stored procedures almost always center around performance. Therefore, it would seem to be easier to code our business logic in an environment more conducive to modularity and reuse. Not that it cannot be done in the database. But if we were to focus on which environment provides greater support for modularity and re-use, I think the middle tier would win hands down.
Security
There is no question that data needs to be secure. But so does business logic. In fact, depending on the kind of business you run, business logic sometimes needs to be more secure than data! So now we have a situation where two areas need protection: Business logic in the middle tier and data in the database.
From the user’s point of view, security should be a seamless experience of behavior and data. Joe would like to make withdrawals (behavior) from his Swiss bank account (data) whereas Jill would like to transfer funds (behavior) from her New York account (data). A common pattern that meets this need is to push the database behind the corporate firewall (thus preventing all access except via the middle tier) and place all security checks in the middle tier. This pattern plays well with business logic coded in the middle tier because often there is a grey area between security issues and business logic and one cannot tell which is which. If you place business logic in the middle tier, you don’t have to!
Transactional consistency
This only applies to stored procedures that start transactions.
Transactions are central to any business. In the classic example from the financial world, you wouldn’t want to make a withdrawal without a deposit. Either they both succeed or both fail. In other words, what is treated as an atomic unit-of-work also comprises behavior or business logic. (Making only deposits and not caring about withdrawals can be a legit business case). So it is logical that the transaction boundary is set in the middle tier where the business logic lives so that it can be maintained along with other business logic.
Caveat Emptor
Having made a case for placing business logic in the middle tier, I have to state: The devil is in the details! For each of the above desirable dimensions, you will find that your mileage may vary. But I am hoping the above illustrates the rationale for moving business logic to the middle tier. There will always be corner cases for which we will have to resort to that stalwart of yore… the mighty stored procedure!
