> According to proper OOP design (or n-tier type design), should these data fields be tied to business object properties and then the business object communicates with the data via getdata(), savedata() type methods?

yes, you get much more flexibility that way in the long run.

>If so, doesn't the whole dataenvironment thing seem to be an impediment to separating the UI/business objects/data?

The built in data environment of a scx based form does seem to negate the use business object to manage data. But the thing to look at is your business object should manage the data environment, not the form. So many of us who use vcx based forms have already given up the "built in" data environment. A common approach for this sort of thing is to use prg defined data environment classes that the business object instantiates as a composite object. For more insight review some of the commercial VFP frameworks and read up on how their business objects deal with data environments and data session handling.

Seems overly complicated at first if your new to business objects, but it actually makes the data environment handling transparent with a well designed business object class. HTH.