PL/SQL vs Java Logic in Oracle ADF - What Should Go Where?

When developing applications using Oracle ADF, one of the most important architectural decisions is where to place your business logic - in the database using PL/SQL or in the middle layer using Java.

Making the wrong choice does not just affect code readability - it impacts performance, scalability, and long-term maintainability.

This guide provides clear, experience-based direction on how to decide what belongs where.

Understanding the Architecture

An Oracle ADF application typically consists of three layers:

• Database Layer - PL/SQL, Stored Procedures, Functions
• Middle Layer - ADF Business Components (Entity Object, View Object, Application Module)
• UI Layer - JSF Pages

A simple guiding principle:

• Keep logic close to where it performs best and is easiest to maintain

When to Use PL/SQL

1. Heavy Data Processing

If your logic involves large datasets, complex joins, aggregations, or bulk operations, PL/SQL is the right choice.

Why:

• Data processing happens inside the database
• Minimal data transfer between layers
• Better performance for large-scale operations

Examples:

• Financial calculations across thousands of records
• Batch updates or scheduled jobs
• Complex reporting queries

---

2. Transaction-Critical Operations

For operations where data integrity is critical, PL/SQL provides strong transactional control.

Why:

• Database ensures atomicity and consistency
• Easier rollback and commit handling

Examples:

• Payment processing
• Inventory updates
• Ledger entries

---

3. Reusable Database Logic

If the same logic is required by multiple systems or modules, placing it in PL/SQL ensures consistency.

Examples:

• Validation rules shared across applications
• Common calculation formulas
• Data transformation logic

---

4. Data-Intensive Validations

Validations that depend on large datasets or multiple table checks should be handled in PL/SQL.

Why:

• Avoids unnecessary data fetching into the application layer
• Faster execution within the database

When to Use Java (ADF Business Components)

1. Application-Level Business Logic

Logic related to application behavior, workflows, or user interaction should reside in Java.

Examples:

• Conditional UI-driven logic
• Role-based processing
• Dynamic behavior based on user actions

---

2. Entity Object Validations

ADF Entity Objects are ideal for row-level validations and business rules.

Examples:

• Field validation
• Attribute dependencies
• Default value logic

Why:

• Keeps validation close to the data model
• Integrates well with ADF lifecycle

---

3. Orchestration Logic

When multiple operations need to be coordinated, Java (especially in Application Modules) is the right place.

Examples:

• Calling multiple services or procedures
• Combining different business rules
• Managing application flow

---

4. Integration with External Systems

Any interaction with APIs, web services, or external systems should always be handled in Java.

Examples:

• REST/SOAP calls
• File processing
• Third-party integrations

What to Avoid

Do Not Put Everything in PL/SQL

• Makes the system rigid
• Harder to debug and maintain
• Reduces flexibility in application logic

---

Do Not Put Heavy Data Logic in Java

• Causes unnecessary database calls
• Slows down performance
• Increases network overhead

---

Avoid Duplicating Logic

• Same validation in both PL/SQL and Java leads to inconsistency
• Always define a single source of truth

---

Practical Decision Guide

Use this quick rule:

• Large data processing - PL/SQL
• Critical transactions - PL/SQL
• Shared logic across systems - PL/SQL
• UI-driven logic - Java
• Workflow and orchestration - Java
• External integrations - Java

---

Final Thought

PL/SQL and Java are not competitors - they are complementary.

A well-designed ADF application uses both effectively:

• PL/SQL for performance and data integrity
• Java for flexibility and application control

The goal is not to choose one over the other -
but to place each piece of logic where it naturally belongs.

Oracle ADF Best Practices, Mistakes and Worst Practices

In this post I am putting some practices and that we should follow while using Oracle Application Development Framework for development

ADF Basics: How to invoke model layer methods from managed bean (Best Practice to write business logic in ADF)

Again a post about ADF Basics for those who are starting with ADF
This topic is posted multiple times and one of the most asked question on OTN

How to access AM method in bean ?
How to pass parameters to model from managed bean (viewController) ?
How to pass taskFlow parameter to model ?

Or sometimes I have to tell user that you should not access ApplicationModule or not update model from managed bean and then i post a link about this
I often post a link of Frank's blog
Best practice invoking business services methods from JSF beans
It is well explained but still user not able to do because he/she doesn't know about clientInterface, pageDef etc

So i thought to write a step by step implementation of this and if you want to know why it is best to call method through binding layer ?
Then please refer Frank's blog :)

What i am going to explain is How to call a method defined in ApplicationModule Impl class in managed bean ?
So for this first i need to define a method in ApplicationModule Impl class




Here i am using Departments table of HR Schema and i have created a method to create new row in Departments viewObject
See implementation part -

• To create AMImpl class--> Open ApplicationModule in editor--> Goto Java tab--> Click on edit (pencil) icon and check the checkbox to generate class
  
  
  
  
  
  


• Now write your logic and create method here so i have created a method to create department record and this method takes a parameter i;e DepartmentId



    /**
     *Custom Method to create row in departments viewObject
     */
    public void createDepartmentRecord(Integer deptId) {
        ViewObject deptVo = this.getDepartmentsVO1();
        Row newRow=deptVo.createRow();
        newRow.setAttribute("DepartmentId", deptId);
        deptVo.insertRow(newRow);
    }



• Next step is to add this method to client interface so that we can access this , Again open AM in editor -->Go to Java tab--> Click on edit icon of clientInterface--> Shuttle method to selected side





• Now to add this method in pageDef , Open page in editor--> Click on Bindings tab (bottom of editor)--> Click on green plus icon of bindings section--> Select methodAction and click on ok






Now select method name here and click ok





Now you can see this method is added in pageDef





• Now time to call this method in managed bean so for that added a button in page and created actionListener in bean . See the code 



    /**Method to get Binding Container of page
     * @return
     */
    public BindingContainer getBindings(){
        return BindingContext.getCurrent().getCurrentBindingsEntry();
    }

    /**Calling method defined in AMImpl class to create new Department
     * @param actionEvent
     */
    public void callAMMethodToCreateDepartmentAction(ActionEvent actionEvent) {
        //Get OperationBinding of method
        OperationBinding ob=getBindings().getOperationBinding("createDepartmentRecord");
        //Passing parameter to method -Get parameter map and use paramater name as key
        ob.getParamsMap().put("deptId", 9999);
        //Execute this method
        ob.execute();
        //Check for errors
        if(ob.getErrors().isEmpty()){
            // Successfully Executed
        }
    }



• Now run application and check , is it working ? ;)

On click a new row is inserted in table with DepartmentId 9999

All done :)
In same way you can call method defined in any model implementation class, remember don't access ApplicationModule or viewObject directly , make use binding layer

and again why it is best practice ?? to know this read Frank's blog :)

Cheers :) Happy Learning