>>>Hi,
>>>
>>>I am using arrays as way to pass the information from UI to BIZ/DA objects but thinking about changing to objects (using SCATTER/GATHER). In terms of memory use, do objects require more memory?
>>
>>
>>If you are considering implementing Business Objects in your app, I strongly recommend that you study and consider a package called West Wind Client Tools for VFP.
>>
>>I recently blogged about my conversion to BO's using West Wind Client Tools here: http://therealmattslay.blogspot.com/2009/08/west-wind-clien-tools-for-vfp.html
>>
>>.
>
>Hi Matt,
>
>I did read your blog and did download the WW Client Tools. I read the help file but not sure if I want to go with their tool.
>
>Thank you.

Some basic get-you-strarted info from my recent West Wind conversion...

The wwBusiness.vcx class library has two class types:

wwBusiness - a single BO class (for fecthing a parent record or a single line item)
wwItemList - a class which will fetch and hold a set of records (like line items on a Sales Order)

I found these classes to be good starting points, but I did write my own wrappers around them and extended their functionality greatly. I would think anyone using the tool set would do the same thing.

Here are the two ways I extended the classes. I would be glad to share this with you if you decide to work with this package.

1. The wwBusiness (single BO class) expects an integer PK to do lookups and fetches. I indeed have Int PKs on my tables, but I sometimes also have a uinique lookup string for each parent record, and I wanted the option of using that for fetching a record. So, I created a Get() method which will accept either an Int or String and will call the wwBusiness.Load(tnPk) for Int PK lookups or it will call the wwBusiness.LoadByRef(tcLookupString) for lookup string. The wwBusiness class already had cPKfield out of the box, and I added a cLookupField property. I created a Factory to push these properties onto each BO when it is created. The Factory data table gives me a nice tabular view of all my Business Object properties.

2. The ItemList requires YOU to write a method to fetch the desired child records into a cursor, then it loads that data into an array when you call the wwItemList.LoadFromCursor() method. Well, that array is fine for procedural processing, but I wanted to host my child records in a grid, so I needed the records to also remain alive in that working cursor so I could edit them, then let ItemList save THOSE records back into the real table from which they came. In my opinion, this entire workflow was the biggest missing part from the tool, and I had to write about 3 or 4 methods to handle this workflow in an abstract way so I could have a generic solution for all my item collections. The main methods I wrote were LoadLineItems(tuParentKeyOrRef, tcMatchField, tcFieldList, tcOrderByFieldList, tcCursor, tlReadWrite, tlCloseCursor, tcSql) and a wrapper around SaveToCursor() which was needed to handle records that had been deleted from the local working cursor.

Lastly, note that using a BO tool in general not only brings you data handling in an object-based mannner with support for various back end data stores, but that same Business Object now becomes *THE* place to put business logic for each of your business objects. Like adding a method for CloseSalesOrder() or AssignJobPriority() or SetDefaultPropertiesForNewJob(), or PrintShippingTicket() etc. With all this properly in place on your Business Objects, creating a UI form becomes a much simpler task of just calling methods on the Business Object. Using this technique, I was able to reduce the code in my CRUD forms by more than 50%!! And now, I have a bunch of cute BOs I can instantiate in code or even right in the command window to work on them without even having a UI screen. Not only that, the same BO can easily support a web-based UI to your exact same data and business logic. It is truly beautiful!

So, as you can see, I did a lot of work on the West Wind classes, but two things: 1. It was VERY fun to work all this out, and 2. It works like a charm, and I now have a completely BO-based CRUD app where all the Business logic is nicely tucked away in the BOs and not in my forms or form controls.