>>>>>Your last line says it all to me: "A disconnected set of relational objects", which could (and will) get out of sync with the authorative source: The database.
>>>>
>>>>Doesn't the problem here lie in the fact that you are allowing datasets (whether typed or untyped) and, in the VFP case, cursors to percolate beyond the data layer. If data is returned from the back end as a set of objects then changes to the DB structure only need to be dealt with in the data layer. And if the objects in .NET are strictly typed the compiler virtually guarantees that you won't cause breaking changes outside the data layer.
>>>
>>>This where things can get complicated. It depends... For reporting purposes there is little escape of data to soak through the data (or BO) layer to the GUI. In VFP, it makes sense to do the databinding directly on the cursor, as well as many .NET scenarios.
>>
>>For reporting that may be true - but arguably only because most reporting tools were designed to work with relational tables :-}
>>
>>>OTOH, the point is that whether you need to address data changes in the data layer or somewhere else, its way more productive to have a solution that has a certain amount of dynamic flexibility so that NOTHING has to be addressed in any layer when certain changes are applied to the database.
>
>>I find it hard to envisage an application with any *real* degree of flexibility - given the myriad possible changes that could be made to a DB I'd think it impossible to unit test against them.
>
>Of course it won't let you get away with all types of changes, but it will with new columns, delete (unused) columns, changing length certain datatype changes and precision of columns, nulls etc. Just think about the old days were you were using DBFs in VFP applications: Database changes are immediately reflected in your client app. Why would I have to to tell the client app about the database structure while it could get that info directly from the source at runtime?
>
>>There are other advantages I can think of in converting to objects ASAP :
>
>>(a) It makes it (comparatively) simple to switch DBs - for example from SQL to a non-relational DB like MongoDB. If the two data layers implement the same interface and serve up the same objects then the only problem is in ensuring that their methods return identical results.
>
>In fact that is what we did... however we did it in one single layer through cursoradapters (though they can be regarded as a sublayer of the data layer). Technically we can support many databases and we did, but when it comes down to the more complex queries it was just unmaintainable. Just plain SQL server is supported everywhere and there is no business sense in supporting other RDBMSs like MySQL or Oracle.
>
>>(b) If the app uses the web at all then, somewhere down the line, you'll be converting datasets/cursors to simple objects (that can be sent as JSON) anyway.
>
>That is what we do for our web portal application.
>
>>TBH, apart from change tracking and use in reporting (for reasons mentioned above) I don't see the point in using Datasets/Cursors at all - especially in, say, C# where 'Linq to Objects' gives you all the flexibility you need to select, filter, sort, etc. on object collections.
>
>It depends on the GUI objects you're using. We are a big user of grids. In VFP, there is no escape from using cursors when using grids.

I guess the architectural design and backend DB of an app is, to some extent, dictated by the choice of language. With VFP the concept of datatables is a common thread from backend to UI and your choices are limited.
A .NET app can be designed in the same way - MS naturally built in a lot of support for MSSQL. But they've changed focus - first with ORM (EF) and then adding POCO. A shift to using simple objects outside the data layer.

To me this is great. Developers working outside the data layer only need to know the interface - they don't need to know (or care about) where the data is coming from behind that wall.