email article printer friendly get the code more resources

Use Custom .NET Collections
Create and use .NET custom collection classes to pass containers of data in your Web services projects.
by Josh Lane

June 2003 Issue

Technology Toolbox: VB.NET, ASP.NET, VS.NET 2003 final beta, ASP.NET Web services

You often need to pass containers of data as parameters into and out of Web service methods. This is a common practice in all types of programming, and it has practical performance benefits for Web services, where the client and Web service might be at a great physical distance. For example, consider the performance implications of a Web service that spellchecks a single word at a time, vs. one that can spellcheck an entire paragraph or document at a time. The network communications costs are significantly higher in the single-word scenario than in the paragraph/document scenario. In general, containers help you group data together; they also help you group together operations against this data—a good thing for Web services.

Using custom .NET collection classes is often the best approach to grouping data. I'll demonstrate how to create such a collection class and how to use it within your Web services code. As an example, I'll show you how to build a Web services-based application that manipulates collections of Employees to provide information about the employees to the user.

You do have several other choices for grouping data, but each has drawbacks. Perhaps the simplest, most obvious option is to use an array. Arrays in .NET are powerful objects, with many intrinsic operations such as a Length property and a built-in binary search mechanism. .NET arrays also have the distinct advantage of type safety. However, a primary limitation of arrays is that they are fixed-length; you can't alter an array's size once it's been allocated in memory. In general, arrays give you low-level, nonoptimized access to the data elements they contain.

Another common option for grouping data is the .NET DataSet. DataSets are powerful, complex data structures with several built-in mechanisms for searching, sorting, and relating the data they contain. They also have other capabilities related to XML presentation and transformation, mapping to and from databases entities, and so on. You can certainly use DataSets as container classes, but beware: All the functionality the DataSet provides comes at the cost of increased runtime resource consumption. If you're dealing with a relational data store in a "disconnected" data scenario, DataSets are exactly what you need. If not, you're probably better off with a more streamlined container class that exposes just enough functionality for your needs.

A third common option is to use classes such as Hashtable or ArrayList as containers. Like arrays, these are simple but useful objects that provide low-level (and, in some cases, optimized) access to contained data elements. Better still, unlike arrays, they can expand or contract in size dynamically; you don't need to preallocate these objects to a given size. The catch is that objects such as Hashtable and ArrayList aren't type-safe; elements they contain are typed as System.Object. If you write a method that accepts an ArrayList parameter, and the method expects the ArrayList to contain elements of type System.String, nothing prevents another user of your method from passing an ArrayList with elements of, say, type System.Double. The result is a runtime typecasting error (at least). As a general rule, you should avoid typing parameters of publicly visible code—including Web services—with these collection classes. A primary goal of Web services is to preserve type fidelity of data passed between clients and servers; generic container classes such as ArrayList and Hashtable make this goal difficult to achieve.