Hi Bob,
Yep I agree totally from an OOP point of view but I was really responding in the vein of the original query - Codebooks "Implementation" of the bizobj and how they can be described.
I've had a look into the persistence layer concept, refrenced by yourself, but I could not really understand what the advantage/utilitarianism of that approach in the database world that Codebook operates in. Yet I feel I am missing something, the idea of a persistence layer intrigues me but seems to be leading me into a maze of coding just so that my code base is academically correct.
Maybe you can enlighten me on what I am missing, as I said above I am intrigued.
Oh and the delay in my response was due to wrestling with upgrading to XP. Well at least the modem works now even if the handshaking is flakey.
Why do I need XP - now I realy don't know. grrrrrrrrr
<i><font color="#663300"><i><font color="#663300">
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.
</font></i>
Well, you are thinking Data, with the BizObj being a class to manage that data.
I prefer to think objects, the Customer Class has attributes and responsiblities. The tables are just a means to store that object.
In the case of an Invoice, on of it's attributes is a 'collection' of line items. Which, in codebook is implemented as another BizObj Class. But, that is the implementation. Having a LineItems bizobj which can't really stand alone.
Also, in the Use Case of Customer, the object could be stored in two tables, a people table which contains person_id, name, age, dob, etc. Then a customer table with cust_id, person_id, credit limit, etc. If you think Objectivly, Customer is a 'subclass' (a specialized version of a person) of Person. Yes, to implement Customer in codebook, you would have to create a view that joins Person to Customer on person_id in each table. Also, the Codebook/VFP implementation only allows you to update one view.
Wouldn't it be preferable if you could do something like...
oCustomer = creatobj('customerbizobj')
With oCustomer
.GetByName('john smith')
.CreditLimit = 1000
.MiddleName = 'boy'
EndWith
oCustomer = null
Above, you changed two attributes which are stored in differnt tables. When you create the cust bizobj you told it that MiddleName was mapped to the Person table, and Credit Limit was mapped to the Customer table. You also told it those tables are joined by person_id.
So, on the destroy of the object, it sees that two attributes have been modififed, so the UPDATE statements are generated by the persistence layer (that is the parent class of the bizobj) and sent to the appropriate data store.
So, when you describe the bizobj as a way to manipulate the data I don't think that is the purpose of a bizobj. That is the implmentation of a bizobj in Codebook.
BOb
</font></i>
©2001 Geof whitham |
