>Databinding in a data centric application is a key concept. Nobody wants to manually bind and unbind values to controls manually. It's an error borne process to do this as it usualy involves code in several distinct place that becomes unmanagable very quickly if the number of fields is large.
>
>This process needs to be easy and require minimum of fuss and preferrably be bound directly to the control not some external object.

I've had two issues with data-binding. One is historical (though still applicable in my case) and the other relates to design philosophies.

The historical: Until VFP made it possible to turn off data-binding in a form, it was a royal PITA to try to bind controls to data in a flexible fashion. If the data didn't exist when the form loaded, all the controls would unbind themselves. Even though there's now a way to unbind and bind controls flexibly, I still have to support Win 95 so I have to stick with VFP 7.

The design issue: When you bind data to controls, that tightly couples data to GUI. This causes two problems:

1. Data validation: Data validation must be done in a user-friendly fashion. Cryptic messages about broken field rules in the database aren't helpful. And if controls are bound to data (even when it's a temporary middle layer between the GUI and the back end), then when the user enters bad data it immediately goes to the controlsource, from which you'll have to remove it. My business classes put validation between the data-entry controls and the business object; if the data's bad, it never gets sent to the controlsource and never has to be removed from it.

2. If you need to present the same data in different ways in different forms, you have to keep rebinding all those controls. I deal with this differently. All of my GUI forms have a single standard interface that a business object can access to read data off a form and transport it to the back end. And the business objects have a single standard interface that the GUI can access to pull data in for display. The business object knows nothing about the names, or even the classes, of the GUI display controls. And the GUI knows nothing about the data objects or tables the business object pulls from. To me, this flexibility has been worth the effort it took to develop the base classes.