Forum Stats

  • 3,826,774 Users
  • 2,260,707 Discussions
  • 7,897,072 Comments

Discussions

Wrapper Java Classes on PLSQL objects

JayArora
JayArora Member Posts: 245
edited Mar 12, 2018 3:06AM in New To Java

Hello Guru's,

I would like to seek your inputs how should we design wrapper classes on PLSQL objects.

https://docs.oracle.com/en/database/oracle/oracle-database/12.2/jjdev/calling-PL-SQL-from-Java.html#GUID-F2FC29B6-F20F-4… https://docs.oracle.com/en/database/oracle/oracle-database/12.2/jjdev/calling-PL-SQL-from-Java.html#GUID-F2FC29B6-F20F-49FB-99CB-56C9C15ECFB5

We can use callabale statements to call stored objects. Our idea is to create java clasess which can call these PLSQL objects and other developers who want to call these plsql objects should create an object of this java class and call appropirate java method. So in future, if there is a change in DB we should only update the wrapper class and the consuming class will not change. We woul also be able to achieve an abstraction  layer.

Is my thought in right direction ? Also, if some one can share some blog/links that we can refer to that would be great.

Appreciate your thoughts.

Regards,Jay

JayArora

Answers

  • Unknown
    edited Mar 11, 2018 8:42PM
    I would like to seek your inputs how should we design wrapper classes on PLSQL objects.

    I'd suggest your question is more related to the BOTTOM tier of DB implementation.

    It is the TOP tier that is the most critical. That tier is the one responsible for dealing with the DB: creating/monitoring/closing the db connection (or connections if you need a pool), handling ALL interactions with the db (dml, result sets, other) and then finally those 'wrapper classes' you ask about.

    You can't really design the wrapper classes until you have mapped out ALL of the requirements for that top tier and designed its architecture.

    We can use callabale statements to call stored objects. Our idea is to create java clasess which can call these PLSQL objects and other developers who want to call these plsql objects should create an object of this java class and call appropirate java method. So in future, if there is a change in DB we should only update the wrapper class and the consuming class will not change. We woul also be able to achieve an abstraction layer.Is my thought in right direction ?

    Yes - that is the right direction.

    But you can't start building the walls of a home until you have built the foundation.

    And for DB work you really need WRITTEN requirements. In 30+ years I have NEVER seen an app that only needed to call stored objects. They always need to be able to at least query one or more tables to get info about what is available.

    It is also very inefficient to do a  round trip to the DB from a client to get one item at a time. That is sort of like making multiple trips to the grocery store to get the items you need for dinner: You send one kid to get milk, another to get meat and so on.

    Much more efficient to make FEWER trips and get as much as you can on each trip. The cost in time and resources is typically driven by the number of trips you make.

    Your use case may be different - but you haven't told us what it is. A similar analogy would be that you can't always go question every neighbor on your block to see if they want you to get anything for them from the grocery store.

    So yes - that is the right direction. The DB layer, and those wrapper classes, should be a BLACK BOX as far as other Java code is concerned. Other code should NOT be involved in dealing with database exceptions or data issues.

    Those data issues include the DB datatypes versus the Java datatypes. That doc example showed a FLOAT being returned. But that may not be the proper precision or datatype for some use cases since float using binary precision while an Oracle NUMBER datatype uses decimal precision.

    Hopefully you are beginning to see why you need at least minimal WRITTEN requirements. Before you even start designing the DB layer you need to identify and specify:

    1. all sources of data that need to be used

    2. all datatypes involved: scalars, objects, LOBs, collections

    3. what DML on actual tables needs to be used

    4. what exception handling, restart and recovery are needed

    5. what types of errors the client layer (as opposed to the DB layer) needs to be aware of and/or handle

    6. what to do when the DB layer or desired data isn't available

    JayArora
  • JayArora
    JayArora Member Posts: 245
    edited Mar 12, 2018 3:06AM

    Thank you for your response and such a detail reply

    I have my existing forms based application and they are heavily relying on DB objects. Although, we are reengineering system from PLSQL to java there are some heavy use cases where we have to rely on DB objects and they could be used by at more than one place.


    I would be calling these PLSQL objects wrapped objects from AMimpl class of ADF which holds an existing DB transaction therefore, i would not be creating any new connection which implies i don't have to close them, the framework would do the job on behalf of us.

    Fetching/Crud operations in application screen we are utilising ADF framework and only complex existing logics we want to re utilise from our forms legacy system that's why my question was focused on it. However, i should have given a bit background of my project needs.

    I am grateful for sharing various parameters that must consider before proceeding ahead.

    I thought black box is just testing concept btw, i am a bit new into it. Could you share some blog/documentation material where i can seek this end to end implementation of a Java wrapper on top of PLSQL and then consuming.

    I know i can do it without it but obviously learning for existing pattern/techniques would fasten my pace.

    I look forwar to hearing from you.


    Cheers,JayArora

This discussion has been closed.