BC4J - Big Project - Business Logic

Question

What is the suggested best practice on where to locate business logic in a big application?
It would appear that entity objects are good for table/domain level validation.
View objects are good to ensure that the data between multiple tables is copesthetic.
But where would one place business process logic that could potentially span multiple views and even multiple application modules?
Also what is the difference between retrieving an application module using the ApplicationModuleHome.create function and from the applicationpool?
Thanks,
Marty
null

Answer 1

re: "duplicate"
You betchya. This is mimicing a SmallTalk implementation I worked with years back.
In some cases, the checks are not duplicated because they share "objects" instantiated for those entities. And in the case of 3 frames all with the same field.. only one check fires ( the active frame where they entered the data ) and all the others don't fire.. they just clean up when the user corrects the data.
In some cases putting validation in the EO appears to just add work at both ends, and adds another layer of confusion for programmers. ( I.E. A programmer is looking at the code.. it is NOT apparent without complete knowledge of the EO code what is and is not being checked. Is that maintainable? maybe, maybe not )
Here's an example of an edit check... confirming that a part number is valid for a custom Find Panel.. and while we're at it, let's turn * to % for a LIKE statement so all our Access users don't get confused:
String oldPart = ((ImmediateAccess)partNumber_tf.getDataItem()).getValueAsString().toUpperCase();
String wildPart = new String();
if (oldPart.indexOf("*") > 0)
{ wildPart = oldPart.substring(0,oldPart.indexOf("*"))+"%"+
oldPart.substring(oldPart.indexOf("*")+1);
oldPart = wildPart;
try { ((ImmediateAccess)partNumber_tf.getDataItem()).setValue(oldPart); }
catch ( Exception e0 ) { System.out.println(e0.toString()); }
if (oldPart.indexOf("%") < 0)
if (!isValidPartNumber(oldPart) )
try { ((ImmediateAccess)partNumber_tf.getDataItem()).setValue(""); }
catch (Exception e0) { System.out.println(e0.toString()); }
boolean isValidPartNumber( String partNumber )
boolean isValid = true;
if (!partNumber.equals("") )
try
Statement call= OpenDBConnections.myJdbcConnection.createStatement();
ResultSet rset=call.executeQuery("SELECT getPartDescription('"+
partNumber+
"') AS PART_DESC FROM DUAL");
rset.next();
if (rset.getString("PART_DESC").startsWith("ERROR") )
statusLine_tf.setText("USER ERROR: Invalid Part Number!");
Toolkit.getDefaultToolkit().beep();
isValid = false;
else
{ status_tf.setText(""); }
rset.close();
call.close();
catch (SQLException esql)
{System.out.println(esql.toString());}
return isValid;
Notes:
1. I do a JDBC call cuz I don't want a lock on my target records. It's a bloody read only request. ( Or is there a way to set that up..as far as I can tell UPDATABLE seems to affect the UI when defined in the View Object.. it has nothing to do with locking? The EO may be updatable by the application... by read only for this particular purpose... )
2. If I understand you right, you are saying to do the IsValidPartNumber code in the validateEntity() method. I want it NOW.. not at commit time.. or is validateEntity "run" on any change to the EO? Or should it be put on the impl setr so that the try catch around the setValue() of the DACF element will catch it? ( I like that )
3. The status line and beeping is managed by the try catch around the dacf setValue(), as well as the clearning of the appropriate DACF control and refocus (if needed ).
4. And that the validation should REALLY be applied to a DOMAIN of "PartNumberDomain".. since it really applies to many EOs with attributes that are of domain "PartNumberDomain".
That last item is VERY interesting to me. I used such stuff in Rdb in the database. Catch is that domain and their power and implementation is scantily described in training and in the online Help.
I'm guessing that when I do a DACF entry that the setr in the EO can be used to validate.. and that the DOMAIN edit gets automatically executed as well.. and that it shows up as a JBOException to the try/catch at the application source level for the programmer to deal with, right?
Note that when Dec/Rdb started on this sorta course 10 years ago, it was clear to everyone that it was a house of ravioli code.. and that without a POWERFUL object repository it was very, very difficult for la rge projects to be built so that programmers would have clear visibility to all the conditions/issues.
Want to bet that you can count on one hand (or less) the number of customers outside of Oracle who have implemented domain validation code and applied it to Entity Object attributes?
Note that in all these cases, I still need to implement the same checks in my triggers to protect the database against ALL comers. So everything gets checked twice.
re: BC4J, wrappers, and java stored procedures. All interesting ideas. I booted that option out during this implementation because the goal was to implement the application... I estimated we'd extend the project another 2-3 months by taking the approach you imply, due to learning curve, conceptual errors on our part during implementation, bugs in the Oracle code awaiting fixing, ad nauseam. That rough estimate has been born out by the fact that JDEV issues of implementation has caused my project to slide over 2 months. Simple, easy things I had alotted a short effort for based on experience with MS Access, Delphi, Forms and other tools turned out to wildly off base. ( Example: the imageControl that simply doesn't work, but is documented as being so easy and quick to put in ).
Thanks again. BTW. If you don't know, I'll be at Oracle HQ on Friday the 16th. Hope to see you again, if just to say hi.
null