views:

41

answers:

2

I have a class in a WCF service, lets call it A. A is a data contract, which contains as one of its DataMembers a collection of another custom object B. To avoid Null Reference problems on the client side, I instantiate the BList in the constructor like so:

[DataContract]
public class A
{
    [DataMember]
    public String name { get; set; }
    [DataMember]
    public List<B> BList {get; set; }

    public A()
    {
        BList = new List<B>();  
    }
}

My problem is that on the client, this instantiation does not happen and BList appears as null after an object of A is created on the client. I'm guessing that the constructor does not appear on the client. So, do I need to make the constructor an explicit operation contract? If so that would make internal things visible to the client that they shouldn't see, right? How do I make sure that this instantiation happens on the client?

Thanks, and sorry if this seems like a dumb question.

+1  A: 

I am not sure if there is a way to do this but by getting the new instance from the service the list should be initialized, I suggest the following

  • Write a web method that returns a new instance of your class and you might use it as the following and I am sure your list is initialized

To create the instance:

A a = new ServiceClient.CreateAInstance();

In the service write the method,

[OperationContract]
public A CreateAInstance()
{
     return new A();
}
A_Nablsi
Thanks. This will probably work but would burden the client by making them call a web method simply to instantiate an object.
Silver Gun
A: 

You need to use [OnDeserializing] or [OnDeserialized] attributes to do initialization of DataContract types. See http://msdn.microsoft.com/en-us/library/ms733734.aspx

Eugene Osovetsky
Sorry, just saw that the problem is deeper than that - you want the *behavior* of BList initialization to transfer over to the client. Unfortunately, there is no interoperable way of doing this (XSD/WSDL/etc don't allow describing such semantics), but you can of course share types (e.g. put your types into MyDataContracts.dll and do svcutil /r:MyDataContracts.dll ) if you don't mind breaking the truly-decoupled / SOA nature of your solution...
Eugene Osovetsky