ADF Best Practices:
1.
Avoid
Web services -- performance issues.
2.
Avoid
JDBC Raw calls – framework already takes care of that
3.
Resource
bundles – Error messages, tooltips and labels
4.
UI
Properties files – File of tokens and matching strings
5.
Clean
check out – everytime when starting a development
6.
One
to Many mapping of EO s and VO s – Using joins in VO s is preferable
7.
Use
ROVO when possible – Helps performance by bypassing the entity cache
8.
Define
VO s at design time rather than at run time – VO s created at run time will
incur an overhead in the performance
9.
Use
named bind variables in queries to filter the data based on a number of
parameters – Can use executeWithParams as a search form
10. Performance – Define how many and what
matter the rows are being fetched
Optimizer hints
Define the query plan the DB will use
when executing a query
a.
While
Developing : ‘jbo.ampool.doampooling’ parameter to ‘false’
As you exit out your
application while testing, re-runs of the application wont be locked by the
application you just exited.
b.
While
Testing : ‘jbo.dofailover’ parameter to ‘false’
Thus disabling application
fail over. This will allow application with out having to save the failover
information.
c.
If
the application uses the same database
user to access application data ensure that you are not running with dynamic
JDBC credentials. Use ‘jbo.ampool.dynamicjdbccredentials’
set to ‘false’
12.
Java Server Faces:
Do not mix JSFs with any other raw HTML tables for layout.
13.
Backing Beans:
The backing bean is a one-stop-shop for the code associated with a web
page and generally speaking it is good practice, if you require code to support a page, to have
one backing bean per page.
14.
Managed Beans:
If it is required to store the state information to be held for the user
interface then this should be done through managed beans.
1.
Avoid
Web services -- performance issues.
2.
Avoid
JDBC Raw calls – framework already takes care of that
3.
Resource
bundles – Error messages, tooltips and labels
4.
UI
Properties files – File of tokens and matching strings
5.
Clean
check out – everytime when starting a development
6.
One
to Many mapping of EO s and VO s – Using joins in VO s is preferable
7.
Use
ROVO when possible – Helps performance by bypassing the entity cache
8.
Define
VO s at design time rather than at run time – VO s created at run time will
incur an overhead in the performance
9.
Use
named bind variables in queries to filter the data based on a number of
parameters – Can use executeWithParams as a search form
10. Performance – Define how many and what
matter the rows are being fetched
Optimizer hints
Define the query plan the DB will use
when executing a query
11. Application Module Configuration
setting:
a.
While
Developing : ‘jbo.ampool.doampooling’ parameter to ‘false’
As you exit out your
application while testing, re-runs of the application wont be locked by the
application you just exited.
b.
While
Testing : ‘jbo.dofailover’ parameter to ‘false’
Thus disabling application
fail over. This will allow application with out having to save the failover
information.
c.
If
the application uses the same database
user to access application data ensure that you are not running with dynamic
JDBC credentials. Use ‘jbo.ampool.dynamicjdbccredentials’
set to ‘false’
12.
Java Server Faces:
Do not mix JSFs with any other raw HTML tables for layout.
13.
Backing Beans:
The backing bean is a one-stop-shop for the code associated with a web
page and generally speaking it is good practice, if you require code to support a page, to have
one backing bean per page.
14.
Managed Beans:
If it is required to store the state information to be held for the user
interface then this should be done through managed beans.
