The "Business Objects Framework" (the "BOF") is a collection of Java classes which serve as building blocks for a typical business application. It is meant to be used with a J2EE-compliant Application Server although it can be used with software which can use the javax.servlet classes.
The main programmatic component of the BOF is the "Bof" class. The Bof class is sub-classed with object-specific meta data and methods (if desired). Classes such as this are referred to as "BOF objects." The Bof class has 183 methods whose scope, for the most part, affects a single BOF object.
Mapping the BOF Object to Persistent Data Sources. The BOF object is typically mapped to a relational database table or a similar data source. Currently, the BOF supports connections to the Oracle and IBM DB2 relational databases as well as the Netscape-derived LDAP Directory Servers. Since most of the relational database functionality is contained in non-vendor specific classes, adding other support for other vendors should not be a major task.
BOF object attributes (variables) which can be accessed using BOF accessor (get/set) methods are "BOF-controlled attributes." All BOF-controlled attributes are stored as Java "Object" class objects (not Java primitives). While any object can be stored as a BOF-controlled attribute, support is specifically provided for the Character, Byte, String, Short, Integer, Date, Long, byte (Array), Float, sql.Time, Double, BigInteger, Object, and BigDecimal classes. BOF-controlled attributes are typically mapped to persistent data store fields within a table, however, BOF-controlled attributes which are not mapped to a Data Source can be used.
Attribute Names and Field Ordinals. Every BOF-controlled attribute is given a name. While any name can be assigned to the BOF object attribute, the convention is to use a concatenation of the class name, the underscore ('_') character and a programmer-assigned attribute name. For example the field name for the account ID in the Account class would typically be "Account_accountId." There may be limitations on an attribute's string length imposed by limitations of specific Data Sources and how the BOF interacts with the Data Source. For example, Oracle has a limitation of 30 characters on field aliases in a SELECT statement, which the BOF uses to populate data in a query operation. As such, field names have a limit of 30 characters when used with an Oracle Data Source.
The BOF also assigns a field ordinal (a Java integer) to a BOF-controlled attribute. The BOF convention is to store this field ordinal in a Java instance attribute which has the same name as the attribute name. For example, the integer value of the "Account_accountId" instance attribute of the Account class is the field ordinal for the "Account_accountId" BOF-controlled attribute.
All referrals to a BOF-controlled attribute are done through the name or the field ordinal. As such, instead of using methods like "getAccountId()," the BofInterface method "getLong (Account_accountId)" is used.
Using the field ordinal versus the field name when referring to a BOF-controlled attribute provides three advantages. First, using the field ordinal allows compile-time checking of the field name. Second, most GUI Java development environments provide for interactive prompting of the class instance attributes, which is a considerable aid for programmers. Finally using the field ordinal results in better runtime performance. There are certain circumstances where referring to a BOF-controlled attribute by name can be useful.
SQL Generation. The BOF object has the ability to dynamically generate SQL code. The SQL generator is efficient - routine SQL code takes 1/100th of a second or less to create on a 800MHz Pentium computer. The SQL generator can create:
Relations. The BOF has a "Relation" interface class which is extended for use by an application. The BOF provides a program which can generate Relation .java programs. The Relation class describes the relationship between two BOF object classes (including a child or parent designation) and the BOF-controlled attribute in each BOF object class which relates them together. A BOF relation can relate a BOF object class to itself, thus providing a way to implement something like a sales territory hierarchy or a management hierarchy. The BOF relation is used for one-to-many relationships. A one-to-one relationship can be implemented through the use of application code and/or Data Store functionality. A many-to-many relationship can be supported either by providing a third object with two relations (which is then easily mapped to a relational database) or it can be supported directly by having two Relation objects relating the same two BOF objects but with the child-parent designation reversed.
The BOF Relation and Database Joins. The relational database join is implemented in the BOF framework by using the BOF Relation class and a "BOF compound" class. BOF compound objects are sub-classes of the Bof class but in addition contains the BOF Relation(s) which models the desired table join(s). The BOF program which generates BOF compound .java files creates code which incorporates attribute meta data from the single-table BOF objects into the BOF compound object. Because instance attributes (used for the field ordinals) cannot be dynamically created in a Java class, there is another BOF program which can be used to maintain the consistency of field ordinal instance attributes in the BOF compound object vis-a-vis the single-table BOF objects. The BOF compound object can perform single-table UPDATE or DELETE operations on any of the tables for which it has meta data on.
BOF Children Lists. A BOF object can have multiple collections (using the Java ArrayList) of child BOF objects with each collection having a distinct BOF relation. The BOF has the following functionality with regards to children lists:
BOF Logging. The BOF Logging feature will record changes made by BOF objects to a Data Source field if the target table has a key field (2-field key fields are supported). This requires the creation of two tables - one table stores which fields/tables will be watched and the other stores the actual changes.