Menu
After reading this post (business logic database or application layer) I still don't have the sufficient reasons to fight the "business logic in database" topic.
In my current work, there is a lot of db transaction (actually) and all that crappy code is hard to maintain, a lot of duplication in the stored procedures, so if you want change a value in a table for a bit, you will need to find all of those procedures and change them to what you want. Same happens if you need to change a little bit a table design.
All the current developers know SQL very well, but they still being not experts in any DATABASE as a engine(8 devs).
Currently we are planning to migrate the entire core to a new version (including database design). And I need some examples of:
App Language: Java
Database: Oracle11g
The application will have Services, served as HTTP pages and as WebServices.
236
The business logic should be placed in the model, and we should be aiming for fat models and skinny controllers. As a start point, we should start from the controller logic. For example: on update, your controller should direct your code to the method/service that delivers your changes to the model.
The very definition of the terms "front end" and "back end" comes from the separation of business logic (back end) from the user interface (front end). So yes, business logic should be in the back-end, whether that is a remote service or simply a different layer in the same application.
Two good reasons for putting the business logic in the database are: It secures your logic and data against additional applications that may access the database that don't implement similar logic.
The Business Logic Layer also known as BLL act as an intermediate between the Presentation Layer and the Data Access Layer (DAL). This layer handles the business logic, business rules as well as calculations.
Crappy code is indeed hard to maintain. That is the nature of crappy code - not where it is located. Moving to a "crappy code in the front end" solution is, well, not really a solution.
And if you think database structural changes won't affect business logic coded in the front end... ummm - logic dictates differently.
I think some things are well handled in the front end, and some things are better handled in the back end. And I think that a proper PL/SQL API design that operates at a business object level can mitigate structural change problems by isolating them from the other layers.
But if there is any thought to supporting other DBs, then this is also a problematic idea as not every DB supports the same constructs.
As to where business logic belongs - that may depend entirely on your application and, indeed, for performance reasons you may find it advantageous to have some aspects of it in multiple layers. That, of course, can cause maintenence issues but this all becomes part of the trade-offs neccessary to deliver a project or product.
But there sure ain't one strict universal answer.
171
Have you read these AskTom threads?
They are good reading and full of great wisdom from Tom Kyte. The only trouble is they don't support the answer you appeat to want - they support the opposite view!
37
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
