>>I've considered binding controls to bizobj properties rather than to fields. But, while this sounds like great object-oriented design, it seems this would be an incredible headache and a real speed cow. With this design you would need to update the properties for every record pointer move. Maintainance would also be problematical. Adding or modifying fields in your tables would require you to go back and update your bizobj structure.
>>
>
>Michael,
>
>Since the bizobj is inherently married to the data structures there is no way to use a bizobj that does require moidification whne the data structure changes.
>
>What is so difficult about having a bizobj.GoNext method that handles the >uopdating of all of the properties for you. In the Gonext you ahve the ability >to have multiple different bizobj classes that handle navigation differently. >To the interface, all there is is BizObj.GoNext and a refresh of the form. The >bizobj decides how to go about getting the enxt record, it may issuing another >SELECT to the backend or it may be a simple skip in a cursor, or it can be a >call to a method of an ADO or RDO. The implementation is hidden from the >interface.

Your first point is a good one. The bizobj is married to the data structure and so obviously changes to the data structure would require changes to the bizobj.

I have no specific objections for a method like bizobj.GoNext() updating properties, but it just doesn't seem like very clean code. My dislike probably stems from my over-enthusiasm to create re-useable code. Hard-coding property updates isn't very re-useable. I tend to try to make generic methods that will work for all cases. However, after considering this I see fault with my logic. Business rules are specific to the bizobj and so generic code is not the goal here.

I do have one question: Do you use data behavior classes? If so, wouldn't that be the object that decides how to get the next record?