Hi,
I agree with the opinion that there is not a magic potion to solve this problem in all projects, in all situations and project evolutions. We can have our Business Logic implemented in DB as the better choice for a project, and this could change to be better a Java Implementation of Business Logic, and reverse. All of the reasons we can read in your questions and responses are good depending on the situations you are considering, and i think that you will not know the best choice at the first of your project life ( development included).
In deep, this is a bet, and the future of your project will decide.
I think that the most important way to solve this question is to be ready to solve a change in this situation or this question when it becomes a risk.
� How can you do this ? I think that you can do it throught flexibility, what you need is to use a flexible well defined architecture that allows you to migrate form one to another strategy attending to your demand.
So your bet could be adapted always.
I know it is difficult, but, a separated level architecture must give you a easy way to do this.
At the First Time, you need a deeper layer for database communication, providing basic operations ( connect, execute, ... ) and dont use this JDBC functions directly from your BL. it will give you a way to change what kind of statement to use, callable, prepared, ..., and much more.
A second layer in deep will provide the data handling, there you can build statements to execute, and use the deeper layer to interactuate with the database. ( how to insert, modify or delete a customer, and another specific operations in my database must be written here )
A third layer in deep where you could write your BL in Java, what to do with a customer , invoking multiple data handling methods.
A four layer in deep where you could write the integration layer of your BL in the rest of the applications, transversal operations, parameter testing... must be done here, before to invoke to the BL.
four layer methods must do common operations, exception control... and call only one BL method.
third layer methods (BL) can be twice:
- If you evaluate that a DB BL is the better choice, your data handling must only call your DB procedures, and the BL java layer must only call one data handling method that builds de call to the procedure and the process of the result.
- If you evaluate that a JAVA BL is the better choice, your data third layer must call and operate on data using propetary code and calling multiples data handling layer methods.
so 1:M or a 1:1 strategy can be implemented, and to migrate, all the application from an strategy to another can be easy, and also can combine both situations, adapting your project situation to the best choice in this moment.
So i think that flexibility in application architecture is the key to bet for a solution with minimal risks. But i think that it will be always a bet, for the best future prediction.
Adolfo.