I would say that your on the right track. The business object always has at least one one to one relationship to the main table (via a view) being created / deleted / updated by the user. Inevitably as the applications become more complex we find it necessary to display other tables. These additional tables appear in the views essentially as readonly, they are lookups.
Adopting the concept of the business object forces all processes that Create, Update or Delete records from a table to go through the business object to accomplish those tasks. It is the linking layer / manager between the Data and the UI. It provides table navigation routines and a way to ensure the data integrity being input by the user through the liberal use of Hooks() processes. I would characterize it as the central processor of CB approach.
I could not totally agree that it is a real world representation. It is a representation of a Customer, but it is normally a representation of part of an invoice either the header or the line items. Even Then it may need more than one bizobj to update line items as you would very likely have an intermediary table e.g ProductParts.
<i><font color="#663300">Not only am I new to Codebook, but new to OOP in general. Since beginning this adventure I have struggled with the business object--specifically, how to conceptualize it. As I was musing on this issue yesterday it struck me that since the bizobj theory holds, 'one updateable table per object', perhaps the business object could be defined as that object which represents the item being modeled by the table. For instance, if the bizobj is bound to the customer table, then it represents the customer being processed in the current instance.
Is this a fair characterization, or have I missed the point? Thanks.
Virgil</font></i>
©2001 Geof whitham |
