Rox,

There's more to this topic than meets the eye…

First of all, if you want to bind UI controls directly to the business object rather than to the VFP cursors, you can do so with the latest version of the Framework with little effort. The question is...*should* you!

In a VFP Tier 1, if you tie all UI ControlSources to business object properties you take a performance hit…particularly when displaying sets of records in grids or list boxes. In addition, when you deploy the business object remotely under MTS using DCOM you take an *extremely* large performance hit. A call to a remote object via DCOM can be a few thousand times slower than the same call to an in-process object. This speed hit has sent developers *running* in the opposite direction!

Plain and simple, VFP is good at cursors. I don’t want to hobble the speed of my VFP applications if I can avoid it…and I *can* avoid it…by allowing business objects to serve up data in multiple ways—whichever is best suited to the client. In a VFP tier 1 this means cursors—hands down. In an Active Server Page tier 1 this may mean ADO recordsets (which is an easy conversion with the new VFPCOM enhancements) or some other technique. The point is, I can use the same business objects (which contain the majority of my application logic) in multiple contexts.

This flexibility of use is what I’ll be speaking about at DevCon and what I’ll be including in our pre-conference workshop at the Southern California Developer’s Conference in August.

Regards,