Vladimir,

Although from a conceptual standpoint it may be "easier" to do without business objects in an application, it ends up being harder in the long run if you don't use them.

In our Codebook for Mere Mortals framework we have carried on the Codebook tradition of using business objects...and for good reason. If you simply use the basic VFP objects such as buttons, forms, textboxes, etc. you are really missing out on the OOP power of Visual FoxPro.

A business object allows you to encapsulate all of the properties and behavior of the "things" your application deals with (for example, invoices, customers, inventory, etc.). You can create these powerful objects and drop them on any form. All of their properties and methods are then accessible to any form in the application. This offers true reusability that is NOT provided by scattering functionality throughout form and control methods.

Typically, developers coming from a non-OOP background will create many functions in a .prg file so that multiple forms and objects can access them. This produces a large .prg file that contains a lot of unrelated functions. It's much better from an OOP, maintenance and RAD standpoint to encapsulate all the functionality associated with an object into a single class.

We also have an Event object in our framework that allows you to encapsulate major events in your application into a single VFP class. This class acts as a director...it coordinates the efforts between multiple business objects to perform a single function. In addition, when you have similar events in an application, you can subclass one event to create another! For example, we have an application where we have a Copy and Copy As event. We subclassed one event to create the other.

If you look in the Project Manager of any application we write you can open up the ABizness and AEvents library and easily see all of the main objects and events in the application. This makes maintenance a breeze!

Hope this helps,
Kevin McNeish
Oak Leaf Enteprises Solution Design, Inc.