AFTER YOUR QUERY IS DONE, THE various techniques discussed in the last chapter (such as ADO Command objects and the ODBC API) still need to pass back the results to the routines that initiated the query in the first place. This chapter explains how to pass the rowsets back (and forth) between the layers.
I'm of the opinion that less is more when it comes to passing data between layers. Because you wrote the query in the first place, and because you also defined the database and its tables (or at least understand the schema), you know how the data should be returned. You don't usually need to be told in any degree of detail how many columns were generated, the datatypes of each column, the updatability of individual columns, or which tables were used to retrieve the data. While this information is interesting to clients who don't have an intimate knowledge of the data layer, it's just overhead that describes schema information you're already very familiar with.
The other aspect of this DDL overkill is that the typical ADO Recordset repeats the same DDL information each time you run the query—not just the first time the query is run. It's sorta like packaging individual potato chips in tiny plastic bags that have the size, weight, and composite ingredients printed on the outside. Wouldn't it be great if we could requery and just get the data—and not all the extra DDL? Perhaps someday.
On the other hand, some developers ask for more metadata, and to be able to use "spandex" properties, and to bind complex validation rules, etc. If you are going to compile and forget your application, less metadata is good for the network. However, for adaptable apps, DDL is crucial. Granted, the OLE DB layer has no thought of optimizing the transfer and caching of metadata. Perhaps someday...
I just came back from VBits 2000 (San Francisco) where I witnessed another preview of Visual Basic/Visual Studio 7. I mention this here because Visual Basic 7.0, like SQL Server 2000, is embracing XML as if it's the answer to the universal question, "What's the meaning of life?" For those of you who don't accept "42" as the answer, you probably won't accept XML as the answer either.
However, XML is a very powerful new paradigm. Will it replace ADO or COM someday, or peanut butter and jelly sandwiches? Although it might prove to be a viable way to cross-communicate between clients and data providers, I doubt if it will replace COM or PBJ on whole wheat. Remember when us old folks looked somewhat askance at HTML and ASP-based Visual Basic Script applications? Well, XML has the potential to be even more important. Stay tuned.
By spandex, I mean the ability to add additional properties to the Field to further qualify, clarify, and extend the metadata.