It is time for me to start publishing some “old” material.
Old material, indeed, however still relevant. I won’t be publishing irrelevant stuff. That seems a wast of my and your time.. Work is busy enough to waste time.
The above presentation grew from a knowledge session at SMART4Solutions. The intention was to introduce my colleagues to some Object Oriented concepts available in our beloved PL/SQL language.
Our application design uses the core-apex schema guideline in which there is a core-schema that holds all tables and business logic and a schema that holds database objects specifically created for use by our APEX application. We call it the API schema or APEX schema. APEX is not allowed to call objects in the CORE schema directly, but should always use a specific package or view that on its turn indeed can call upon the object in the CORE schema.
It seems a bit of extra work, but in this way we ensure that our APEX application will not break down due to changes in the database. If, for example, a column gets renamed, the view in the APEX schema will get invalid, in which case we know we have to make a change in the view, but also need to see if this has implications for that specific APEX page.
The idea now focuses on the CORE schema. How can we further divide the business logic inside that schema. Is there a way in which we can focus solely on business logic without having to worry about techy stuff: CRUD operations in general. With PLSQL-OO we can.
We create ourselves a type for each table which holds all the attributes and a couple of procedures and functions:
- save_to_db: save the type (record) to the database, regardless of an insert or update
- delete: deletes the record form the database