Here is the beautiful stack of Business Object classes for my Line of Business CRUD app (see image below).

The Job object (highlighted in the screenshot), in particular, is populated with tons of little worker methods to handle all the processes my Job oriented forms need. Most of these methods were created by taking little bits of procedural code from various forms and procedure files that had become strewn about all over my app code, and tucking it away into methods on the Job class.

Now, I can easily create a Job object with one line of code, and then call any of its handy methods to quickly create a cursor containing the desired child records, or return a value from some other calculation, or any other tasks that my business app needs to handle. 

So follow this rule: If you’re writing processing code in form methods or methods on UI controls (yikes!), you should consider creating a Business Object and adding methods to it instead. It will be much more re-usable and maintainable.

Code sample:

oJob = CreateBusObject(‘Job’) && Call a Dictionary method to get the class

oJob.Get(‘TheJobNumber’)

If oJob.lFound = .T.

   oJob.GetLineItemsForInvoice(‘CursorName’)

Else

   *– Handle Not Found situation

EndIf