Web Service Proxy Collection Types

SOAP-based web services are self-documenting.  This means that tools like Visual Studio can create a proxy class for us based on the service description (generally with WSDL -- the web service definition language).

Collection Types
SOAP web services are designed to be interoperable.  This means that we can consume a SOAP web service with whatever development environment we are using (.NET, Java, PHP, etc.) regardless of the language that the web service itself is written in.  (The converse is also true - we can write our .NET web services so that they can be easily consumed by other development environments.)

When talking about interoperability, this usually means that we are coding to the lowest common denominator -- meaning that we use the constructs that can be understood by the most development environments.  For collections in .NET, we have a tendency to use a generic list such as List<T>.  But when thinking about interoperability, we need to consider that generic lists do not exist in every environment, and so we take a step down to an Array object.

When consuming web services, we run into the same issue.  The service may expose an Array object as a return type.  But we would much rather use a generic list in our code.  So, what do we do?

Did You Know? Advanced Proxy Settings
The Visual Studio service proxy generator actually gives us control over the types of collections that are exposed by our proxy.  When you select "Add Service Reference" for a project, the resulting dialog has an "Advanced" button.  If we click this, we get the following screen:

If you have already created a service reference, you can also get to this screen by right-clicking on the service reference in the Project Explorer and selecting "Configure Service Reference".

Notice that there is a setting for "Collection Type".  The default for this will vary depending on the environment and type of service that we are consuming.  For example, the sample above is a SOAP 1.1 service, and so it has defaulted to the Array collection type (System.Array).  But we can change this with the drop-down:

This lets us change from Array to List<T> without having to do any casting or conversion in our code.  All of this is handled for us in the proxy that Visual Studio creates for us.  Any Arrays that are specified in the service (either as parameters or return types) will be converted to generic lists automatically.  Pretty cool, huh?

You can see that we have a number of options to choose from.  The List<T> (System.Collections.Generic.List) is just one of them.  We could also use an ObservableCollection (which has special features in the XAML world) or one of the other types that meets our needs.

If the services are using Dictionaries, there is a similar option to choose the specific dictionary type -- whether a sorted list, generic dictionary, hashtable, or something else.

SOAP Services Are Still Cool
SOAP services have been getting some bad publicity lately ("They are too verbose") as people move toward REST services.  But like everything else in the programming world, there is room for both.  Each have advantages and disadvantages; it's our job as developers to weigh those benefits and costs and determine which is appropriate for our situation.

The big advantage to SOAP services is that they are self-describing.  This means that we can use tools such as Visual Studio to create a proxy class that makes it extremely easy for us to interact with the service.  (Most other development environment have this same sort of WSDL importer tool.)

Visual Studio is a great development environment that gives us quite a bit of control over how the SOAP service proxies are generated.  We've seen how we can control the collection types; you can take a look at the "Advanced" features to see what other options are available.

Happy Coding!