The BC4J framework combines the best of both the relational database world and the object oriented world in how it implements the collaboration between view object and entity object components. J2EE developers talk about implementing the "Fast Lane Reader" design pattern, to give flexible SQL access to your data in the fastest way possible and to allow the developer to select only the data they need. BC4J's implementation of Fast Lane Reader is coordinated with an automatic coordination with the backend business components that encapsulate and enforce the business rules. Normally, this coordination would need to be coded by hand by a J2EE not using a framework like BC4J to do something like:
- Possibly modified data comes back from the client in a Data Transfer Object
- Need to figure out which attributes in the DTO have been modified
- Need to find the appropriate underlying entity or entities by primary key
- Need to call the attribute setter methods for the modified attributes on the underlying business object to transfer the data from the model layer back into the business object layer
BC4J does this automatically as described in Section 8.1 ("Partial Object-Fetching and Middle-Tier Caching") of my first BC4J technical whitepaper on OTN. The way BC4J works, we use JDBC to query just the data you ask for in your view object's SQL query, storing that data in the underlying entity objects. This means that if you have queried only the order number and the order total for an order, only two of that Order entities attributes are populated in memory: a great savings versus fetching all attributes for all rows.
It's only when you go modify a row in the view object that we go "fault-in" the missing entity attributes using the primary key (calling your entity object's doSelect() method in the process to get the job done). We fault-in the missing attributes for modified or deleted rows so that your custom business logic can be coded assuming all attributes are always in memory.
Since in most business applications, you do a lot more reading of data than writing/changing of data, our feature to allow entities to be partially populated in memory until they are modified saves time and memory. The fault-in occurs for one of the following reasons:
- You have tried to setAttribute() on a existing entity object instance which is currently STATUS_UNMODIFIED.
- You have caused the underlying entity object to be locked in the database (if you are using optimistic locking mode, this won't happen until your post-or-commit your changes).
- Some business logic you have written attempts to access an attribute of the entity that is not presently populated in the entity). For example, you queried OrderId, and OrderTotal in a view object, but end up executing some business logic that calls getOrderDate() as part of its calculations.
- You explicitly call findByPrimaryKey() on the entity's definition object
If you are overriding the doSelect() method yourself, then the boolean flag that is passed to you by the framework indicates whether you should lock the row as well as reading its currently values in from the database.
1:48:28 PM 
|
