views:

25

answers:

1

I've got several data contract classes like this:

[DataContract]
public class FooData
{
    [DataMember]
    public string Name;

    // ... many more members

    public FooData (string name) // again, many more arguments
    {
        Name = name;
        // ...
    }
}

Since FooData is always used to transport Foo objects over the wire, I'd like to add an constructor that takes a Foo object and sets all fields accordingly instead of doing it manually (new FooData (myFoo.Name)).

However, this would require the user of FooData to include the Foo type, which is supposed to be internal to the server. Ordinarily, this issue would be solved by making the constructor taking the Foo internal, but in my case FooData is in a different assembly than Foo.

How should I deal with this? My thoughts so far include using an interface instead of a class to transport data as well, or using an "extension constructor". Any better ideas?

+1  A: 

Including the Foo type on the constructor should not be a problem as long as you don't expose that type in a public property marked with DataMember. WCF will take care of serializing only the properties marked with DataMember, so you can internally use your server types in the data contract. However, the client will not able to see that constructor that receives the "Foo" type, so it will have to set all the data in the contract manually

Thanks Pablo.

This does not work - the client includes the source file, and the compiler is going to choke when it notices the internal ctor that takes an argument of unknown type, right?
mafutrct
No, that's not right. The client should get a copy from the data contract classes after the proxy is generated with "Add Service Reference". The client should not reference the data contract source files directly.