<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>
Actually, the business object is a representation of a 'real world' entity or event. Such as a Customer or an Invoice. The table is just how you would persist or save that object.
When designing OOP programs you want to model your OBJECT's first, then figure out what tables you need to store them. Actually, I am starting work on a persistent bizobj class that you can use a tool to map each property to a field in a table and the persistence engine will do all the work of retrieving and saving the object, so you never have to write any data handeling code.
You've heard of seperating the UI from the Busness Layer, well this will seperate the business object from the storage mechanisum so the programmer doesn't have to worry about it.
I am hopeing to be able to use or modify Codebook's UI classes to use these new persistent bizobj's.
BOb
©2001 Bob Archer |
