SOA WCF class design for collections of objects, or "has-a" object situations.

Question

We are designing an object model from scratch for an application that will expose data via WCF. We are wondering about how to handle the case where objects that have a collection of objects within them. For example, a contact object with a collection of address objects.

contact - list<address> 

Should we have a wrapper object, something like "AddressCollection", that has properties of its own like "hascollectionloaded", for lazy loading of the collection, and other things we havn't thought of yet, or should we just rely on the list<> as above?

contact - AddressCollection - list<address>
                            - hasBeenFullyLoaded
                            - preferredObjectLoaded
                            - somethingElsePertinent

For the example above, could we let the AddressCollection inherit from an abstract base class or interface implementing the "hasbeenloaded" and "somethingElsePertinent" properties?

OR, even implement another bool property on the contact object itself "hasaddressloaded".

contact - list<address>
        - hasaddresscollectionloaded

Likewise, how to implement a custom object on the Contact that isn't necessarily a collection? For example:

Contact - Status

OR

Contact - StatusObject - Status
                       - hasStatusLoaded
                       - somethingElseWeWantToKnow

Answer 1

You question is a bit ambiguous but I'll give it a shot. Hopefully we can get you to an answer with some back and forth.

First of all, it doesn't really matter how you return your collections using WCF. The DataContractSerializer will serialize them properly on the wire. For .Net clients they can maintain the original collection types. The other subscribers (Java for instance) will get an array.

My first suggestions would be:

A) Use Contract First development to create you messages. Your service should be autonomous and provide a separate request and response for each call. This will allow for greater flexibility later and will also lead you to a better design.

B) You really shouldn't expose List to the outside world, instead expose a Collection or a ReadOnlyCollection.

Hopefully this will point you in the right direction. If not, maybe we can figure out what your ultimate goal is and we can work from there.

So far this is all I see from your question:

[DataContract]
public class AddressResponse
{
    [DataMember]
    public Collection<Address> Addresses { get; set; }

    [DataMember]
    public string Status { get; set; }

}