Hi Christof,

>
>Business objects require more memory than procedural code. They are slower, too. FoxPro is fastest if you define your forms in code and put all data access code into the click event of the save button, preferably without calling any other functions.
>
>Does that mean you should write apps this way? No.
>
>What you should do, though, is carefully evaluate the need of copying data. In VFP the most efficient way to handle data is a cursor or a table, not an object, not an array, not a collection. For single records, scatter objects and arrays, both come close. Objects are more maintainable than array in the long run and are easier to handle than cursors when passing them across data session boundaries, though.
>
>I found one problem to be that there's virtually no literature about business objects in FoxPro, Access, Paradox, and other database centered languages. Most examples are written in Java, .NET, and similar languages. In these languages you absolutely have to pass data as an object. Doing so is the native and quickest way. Copying data from one object to another object isn't a very time consuming operation and mainly depends on the size of data. Not so in VFP. Creating new objects to hold data is 30 times slower than adding a new blank record to a cursor. Extending an array and storing data is 100 times slower than APPEND BLANK. (tested on my machine with 100,000 iterations).
>
>Literature says you should use objects and pass them around, because that's their only option, not because it is the best one in VFP.

I totally agree with everything you are saying. I mean about the lack of articles on building BO in FoxPro and that FoxPro has some fast tools (like arrays and cursors) and they should be utilized, instead of objects, as in some other languages.

Cursors are of course the fastest way of moving the data around in FoxPro. The only downside is that cursors cannot be passed to a private datasession object. Although Srdjan shows that with some jumping through hoops it can be done. And I have considered that but I end up using a different approach.

I have two DAL classes for data handling. (one for retrieving and one for updating).

1. DAL for DataFill. The entire purpose of this class/object is to get data required for initiail UI form view into a cursor from either VFP database or SQL Server database. This datasession of this class is not set to private. Therefore, when the cursor is populated in this object it is readily available to the UI form.

2. BO and corresponding DAL for business rules, updates, adds, etc. That is, when the data has to be sent back to the Database. This BO/DAL class is in private datasession. And for the most part the data sent from UI to BIZ is one row (in some cases a few). So in this case I convert the row of data that has to be passed to the BO using array of field name and value pairs. And for some reason I thought that if I change from array to object (using SCATTER/GATHER) things will work better (faster). But based on the input in this thread, I won't go the SCATTER/GATHER route. I will stay with arrays.

Thank you for your input and suggestions.