Thanks for the clarification.

You mentioned decreased performance - are you saying that taking the code out of the form and putting into PRG's will cause a decrease in performance - or are you saying that using the COM objects and such will cause a decrease in performance - or both?

>Claudio has given you some good references to in-depth discussions of business objects. Another is Alan Griver's "Visual FoxPro Codebook" if you can still find a copy of that. That book basically introduced the concept of business objects to the FoxPro world, and lives on in Codebook-based frameworks like Visual FoxExpress and Mere Mortals.
>
>The big advantage of business objects is they allow you to move away from monolithic apps where everything is written in one language and runs on one processor. If you want to change one of those apps to use a different back end or a different GUI, you have a major rewrite on your hands. Let's say your GUI and your business rules are tightly linked -- VFP forms with validation logic and business rule enforcement handled by Valid methods in those forms. Now let's say your company or client wants a web browser interface. You not only have to re-do the GUI, you have to reimplement everything that's in those Valid methods, too. It's nice to be able to isolate your validation and business rules from the front end and the back end.
>
>This gives you a lot more flexibility. Business objects don't have to live in the same executable as the front end and/or back end. Nor do they have to be written in the same programming language. You might like to use VB or ASP for your GUI layer and do your validation by calling COM objects written in VFP. (Microsoft has at times described VFP as being well suited for middle tiers, although apparently not outside the VFP developer community ;-( ). The implementations of your different tiers don't even have to be on the same box, i.e. DCOM, MTS, and the like.
>
>Of course, that flexibility comes at the cost of increased complexity and probably decreased performance, especially in a distributed environment. It isn't something you want to take on just because your friends are doing it, put it that way.
>
>Mike