ADF : Refactoring/Modularizing your AMImpl code

Lot of our ADF Applications use a single Application Module(AM henceforth) to house most of the business logic. Thus results in a huge AMImpl.java which keeps growing and eventually becomes difficult to maintain with multiple developers working on it.

With this file being the heart and soul of the application , it would not hurt to refactor the business logic within it to separate standalone Java classes which can be separated out based on some functional/logical separation.

This can be easily achieved by calling these standalone Java classes from the AMImpl.java and passing the AM instance to them so that the required operation could be carried out independantly and in context.The AMImpl.java just houses the skeleton methods to call the standalone Java class methods.

Example

Code in <yourAMName>Impl.java

       public void scheduleJobViaAM(){ // this could be called from the UI via method call in a Taskflow

        Scheduler scheduler=new Scheduler(); // can be made a static class as well based on need

        scheduler.scheduleJobsViaQuartz(this);

    }

Code in StandAlone java class

    public void scheduleJobsViaQuartz(ApplicationModuleImpl am){// accepts an instance of super Class of our AMImpl.java'

         OrgAMImpl orgAM=(OrgAMImpl)am; //typecast AM  to its appropriate Impl class to get access to its method and objects

        orgAM.commitSalaryForEmployee(100); // call AM method to do processing with its VO Instances , alternatively that code could be written here too since we have a handle to the AM instance !

 }

Finally we have more readable , manageable code which goes a huge way in having a timely delivered project with minimum issues  !