Feedback requested: in backing bean, use AM svc method or operation binding

Question

Hello all,
I'm posting this here to solicit feedback from both Oracle and from the community at large. The basic question is around what is the best/better practice for calling Application Module service methods from a backing bean. One choice is to call the service method directly on the application module; the other is to put an operation binding in the page definition and to execute that binding. The basic code for the two methods:
((MyAppModule) getBindings().getDataControl.getApplicationModule()).serviceMethod();or
getBindings().getOperationBinding("serviceMethod").execute();My question comes up specifically because of differences in how the default error handling works. For testing, we created a simple AM with a single service method that throws a JboException (a kind of RuntimeException). Then, we created a simple ADF Faces page with an af:messages (to see how error handling works) and four af:commandButtons. The four command buttons are as follows (the code is in the backing bean for each of them):
1). partialSubmit=false, calls application module service method directly
2). partialSubmit=false, executes service method via operationBinding
3). partialSubmit=true, calls application module service method directly
4). partialSubmit=true, executes service method via operationBinding
None of the backing bean methods catch any exceptions. Note that #2 and #4 could be bound directly to the methodBinding in the pagedef, but we did it via code in the backing bean to more accurately mimic some of the code in our application; in any case, the results were the same using either method for #2 and #4.
The results when clicking each button:
1). ugly stack trace in the browser window (yuck!)
2). the af:messages component displays the JboException (nice)
3). No stack trace, no error message (even worse than #1, user thinks "success," even though exception occurred)
4). the af:messages component displays the JboException (nice)
This leads me to think that perhaps calling via the binding container is the preferred method because the default error handling gives acceptable behaviour, whereas using the AM directly gives unacceptable behaviour.
Another "benefit" of calling through the binding container is that the technology in the model layer could be changed without having to change the view layer. I say "benefit" in quotes because I personally believe that one should write applications to take full advantage of the technology they choose, not try to strive for technology/database independence (no flames on this one please - that's not the main point here ;).
Having made the preliminary conclusion that the binding container is the preferred way to go for service methods - that could then ostensibly be extended to view objects as well. Should the view layer use iteratorBindings instead of dealing with view objects directly as well? This is a bit more shaky ground because there are some points in the view/controller layer (namely managed beans not associated with any page) where there is no binding container available. However, in backing beans, for re-executing queries we could make the "best practices" statement to always use iteratorBindings instead of accessing the AM/VO. I just completed a test comparing view object usage vs iterator binding usage (vo.executeQuery() vs myIter.executeQuery()) with similar results to the AM testing - the binding container route gives acceptable error handling, whereas the VO route forces me to implement my own error/exception trapping and message display.
I am aware of one drawback to using the binding container instead of the AM directly - that is that each page that needs the service method must have something in it's pageDef for that method. Originally, we had some code in a superclass of some backing beans that called the AM directly, and we didn't need to touch the pageDefs of approximately 20 JSF pages - when changing to use the operation binding - we had to add it to a lot of page defs.
I'm very interested in feedback from the community at large on my conclusions. If the discussion gets to be too big/complicated for here, we can change venues to perhaps the oracle wiki or another forum. I did do a quick review of SRDemo ADFBC and noted that all of the service method calls are done through operation bindings - I never noticed that before! Most of the discussion we see in the forums shows people calling them directly, which is why I thought it important to post here.
Best regards,
John

Answer 1

What we did in our project was that we create a "Headless" pagedefinition, (that was how it was described in SRDemo documentation or in JDeveloper help, its on the latter part about Security).
You have to create that pagedef manually. and it only has an
<page id="yourPageDef_Id" path="..."> entry in your Databindings and no
<page path=".../yourPageDef_id" usageId=".../???.jsp">And then in your faces_config and your managed bean name is backingSystemStateBean and is located at path.to.bean.SystemState add a Session scope bean entry like this:
  <managed-bean>
    <managed-bean-name>backingSystemStateBean</managed-bean-name>
    <managed-bean-class>path.to.bean.SystemState</managed-bean-class>
    <managed-bean-scope>session</managed-bean-scope>
    <managed-property>
      <property-name>bindings</property-name>
      <value>#{data.yourPageDef_Id}</value>
    </managed-property>