Thursday, October 24, 2013

some best practices



The ADF Framework promotes the MVC pattern through the use of a well defined view, controller and model layers. The view layer is the JSPX fragments and associated backing bean code, the controller is the binding layer (ADFc) and the model is the business layer, typically ADF BC. A central tenet of the MVC pattern is that view and model communication is orchestrated by the controller layer. 

In some implementations, the backing bean code often directly invokes the Business tier directly without using the binding layer. The end result of this is a tight coupling between the view and model layer, where changes to the model layer could easily break the view layer code.Such implementation is also at risk since the benefits of the controller layer like contextual events, or deferred execution cannot now be performed. This also makes the code difficult to customize and change later.

Recommendation:
Re-factor the view layer code to use the binding layer. The view layer code should not directly invoke business methods, bypassing the ADF controller or the binding layer.

For example if you need to use any method define inside the applicationModule class, DON’T make a reference of the applicationModule in your code instead bind this method to the page and use the below code to access it:

         BindingContainer bindings =BindingContext.getCurrent().getCurrentBindingsEntry();
         OperationBinding submitTable = bindings.getOperationBinding("OperationName");
         submitTable.getParamsMap().put( "Parameters" , "data" );
         submitTable.execute();

---------------------------------


Best Practice for iterating over View Object rows
Create a secondary RowSetIterator if the business logic needs to iterate over rows of view. Note that the default RowSetIterator is typically bound to the UI components and use of it in
business logic will give inconsistent results at runtime. Call closeRowSetIterator() on the RowSetIterator instance once the business logic is done with the iteration. An example would be as follows:
public void checkAllPolicies() {
RowSetIterator policyRSI = null;
try {
ViewObject vo = findViewObject("PolicyVO");
vo.setNamedWhereClauseParam("policyNumber", getPolicyNumber());
vo.executeQuery();
//Create secondary row set iterator
policyRSI = vo.createRowSetIterator("customRowSet");
while (policyRSI.hasNext()) {
Row policyRow = policyRSI.next();
// -- business logic
}
} finally {
//Close the secondary row set iterator
if (policyRSI!= null)
policyRSI.closeRowSetIterator();
}
}


When iterating over view objects that are also used in the UI, the access mode can be set programmatically at runtime. You can restore the original access mode later based on the use case. The advantage of doing this programmatically is that you can use the forward-only mode only when needed, while other users of the view object, like the UI, will not be affected.
public void iteratePolicyVO() {
ViewObject vo = findViewObject("PolicyVO");
byte origMode = empVO.getAccessMode();
vo.setNamedWhereClauseParam("policyNumber", getPolicyNumber());
//Set access mode to FORWARD_ONLY
empVO.setAccessMode(ViewObject.FORWARD_ONLY);
vo.executeQuery();
while (vo.hasNext()) {
Row policyRow = vo.next();
// -- Business logic
}
//Restore the access mode
empVO.setAccessMode(origMode);
}
  ----------------------------------------------------------

Please make sure that you take care of the following in your code.

1      All the beans that you use in your code irrespective of the scope should implement searializable.
2      As a best practice for ADF, try as much as you can to not use binding for the UIcomponent and if you really need to use it, don’t use it in a memory scope more than Request or Back bean
scope. UIcomponent binding is only valid in request scope and backing bean scope. UIComponents are non-serializable, and therefore cannot be stored into any memory that would cause them to live longer than one request. If you need to keep a reference to a component longer than that you may use a component reference.

Please check the below link:

See “2.6.3 What You May Need to Know About Component Bindings and Managed Beans”

        Review your code and make sure you do the following:

1      Remove UIComponent Binding if there is a alternative way to do the same logic
2      If you must use it, make sure that you don’t use UIComponent bindings in beans that live longer than request scope and backing bean scope.
3      This is the last option. In case you have used component binding in beans with scope higher than request scope and backing bean scope, you can use  the component reference API to make the UI component also searializable.

No comments:

Post a Comment