>>
>>In Codebook, a business object contains a DELoader object which is responsible for loading/unloading the cursor(s) associated with the business object. Once a cursor has been loaded, any user interface control on the form can directly reference the cursor's fields in its ControlSource property.
>>
>
> How would a parameterized view work? What would be the "correct" way to pass the parameters to the view? Through an object property? Since most people seem to consider global variables the work of the devil I figure they should be passed some other way.

In a client-server environement you don't want to pull down large data sets. So, for the user to pull data they need to specify something on the form, a search criteria. A good example of this is a "user" form which lists the users of the system along with their phone numbers, addresses, etc. When the form first comes up it would have no data. The user would have to enter a last name or partial last name (for example 'B') to bring up that data subset. They could then navigate through that set of records normally. So, in this case, the view parameter would be based on a users last name and your requery would be assigning the view parameter from the value of the search textbox.

In this example, the requery method could declare the view parameter private. Thus, once the requery is done the private variable is released.

>
>
>
>On another note, I'm wondering how a Invoice object would be implemented. In a few of the books I've read, they seem to show an invoice object as a "Container" that contains line objects. I can't imagine trying to create a separate object for every line that an invoice would contain. It seems like it would be much easier to write a lines (multiple lines) class that references a DE object that is made up of a view of the individual lines. This lines object would then be contained in Invoice object. Is this a reasonable way to implement this? If you were to do it this way, you'd need a method that calculated line totals and invoice total. Should both methods be contained in the lines object? Or should the lines object only calculate one line at a time, and have the Invoice object call the lines object for every line in the invoice, then make that value available via a Method call/Property setting (which seems like the wrong way to do it to me...)?
>
>-Paul

Actually, the example of this type of thing I have seen has used a collection class as the invoice object. The collection class would then be able to add child line items. Remember in OOP you want each object encapsulated, so it is better design to make a line object rather than a lines (plural) object. But, as is the case with any programming language, how "pure" you write your code is up to you. You could be correct; the overhead of managing x number of line object might be prohibitive.

Line total and invoice total calculations should be the job of the invoice object rather than the line object. The line object shouldn't care about other line objects at all. The invoice object would need to merely ask each line object what it's total was and add them all up. In addition, you could have special line calculations for things such as averaging labor into the cost. So, if the invoice object wanted a base cost, it could call each line object's GetBasicCost() method. Or if the invoice object wanted to have the labor included in the cost it could call each line object's GetLaborCost() method.