>>The design has held up very well as the framework has evolved since then. In the last three years Mike and Toni and I have been doing all our development against SQL server so there has been a lot of thought about that, especially about means of minimizing wire traffic. ( for example bizobjs that use two cursors - one for the list returned by the parameterized view for further selection - it contains only fields needed to pick a record - and a data entry cursor that contains only one record but all the fields. Makes a huge performance difference in some cases )
>
>Neat idea. I've often caught myself saying that for most of the tables we need two ways of handling them - one long and narrow, other short but wide. Putting them together sounds like exactly the spark I'd expect from the Feltmans :)
>
>>What really amazes me is how many apps are being written in VFP that are table based rather than view based. that seems like the most masochistic implementation of Foxpro, but in almost every case where I questioned someone as to *why* they worked directly with tables the answer boiled down to they didn't know *how* to do it with views.
>
>My only gripe with views is that in a sufficiently complex app, the views' dbc becomes very large. I'd rather use SPTs handled by .prg based classes - but that's just a matter of taste.

I have a number a number of apps I'm mentoring with over 800 views in one dbc ( I would have designed it in a little more of a segmented fashion ) and the dbc really isn't very big.

I've found the views dbc requires packing frequently during development.

The upside of the views dbc is its coordination with the metadata store. We can have multiple indexes on views, just as we would on tables. They can also store the dynamic params metadata etc. And of course part of the metadata defines the cursor class that will be instantiated for each view, so further customization is available there.

And of course the remote views as we use them are just wrappers for SPT anyway.


When working with team apps and source control we often make the views dbcs pretty granular so somebody can check out the dbc along with the class libs for the cursors, data evironments, bizobjs, and presentation layer for whatever they are working on.