Recently, while working on a few enterprise-wide projects for a Fortune 500 company, I ran into some interesting choices regarding my COM objects' public interfaces. I was trying to solve the basic problem of uniformly sending a variable number of parameters and/or a collection of records to a single method. I decided that to make the method generic, it should have only one parameter that would be some type of data structure containing all the data for the method. This approach makes the interface nice and clean, and other similar COM objects can easily implement it. (I won't go into the specifics about the method, interface, or application because that isn't this column's point. In a future column, I'll discuss these issues, and I'll specifically address the role that XML plays in each issue.)
The first approach that came to mind was to use an ADO Recordset object. ADO Recordset objects contain a lot of metadata, the records are easy to iterate through, and they are self-marshalling (i.e., they take care of getting their data from point A to point B without you having to worry about it).
As a huge ADO fan, I was intent on using the Recordset object as my parameter for my method until I realized that this application was an enterprise application, and some users who might use this COM object might not have ADO or the right ADO version installed on their machines. So, I decided to compare using an ADO Recordset to using an XML string for the parameter of my method. Below are some of the pros and cons for using a single XML string as a parameter for a method:
- Methods can have one argument (an XML string)
- No data marshalling involved (it's simply a string)
- No need to have anything special installed on the client (e.g., correct ADO version)
- Excellent for achieving polymorphism
- Need to be able to build the XML on the sending side and parse the XML on the receiving side, which can be very expensive (see http://www.asptoday.com/content/articles/20010202.asp for a comparison of using different data types to pass data in a multi-tier environment)
- Need to have intimate details (e.g., a schema/Document Type Definition—DTD) about the structure of the XML
I concluded that I could easily use an ADO Recordset object as the parameter for my method, and it would probably outperform the XML alternative. However, I decided not to use the ADO Recordset. Because so many people would use my object and because I wanted to keep the interface as clean and simple as possible, I decided to use the XML string as the parameter for my method. Although the XML isn't as efficient, it's much more flexible and more conducive to a large group of users. In a future column, I'll explore how XML can help achieve polymorphism in COM objects.