I’m developing an application in C#3.5 that uses WCF.
I have had many issues dealing with the serialization of the objects in the communication.
Taking the codes of CSLA as a good dessign pattern, I discovered that I should use NetDataContractSerializer instead of the default XmlObjectSerializer that doesn’t keep references.
Now, when passing arguments in the WCF calls, I’m getting the exception “MyCollection is an invalid collection type since it does not have a default constructor”
Reading the book Expert VB 2008 Bussiness Objects, page 165, Non-Public Default Constructor topic, it says that every business object should have a default constructor, even if it is not for public use.
Here is the question:
The reason Lhotka says every business object need to have a default constructor is because WCF and the issues I’m having when serializing with the NetDataContractSerializer? Or there is another reason?
I want to be sure that I’m designing correctly and the dummies private default constructors are really needed.
I don’t want the consumers to use my constructors, but the static methods, that’s right. But that doesn’t mean I need to have private parameterless constructor. In some cases I have private constructors with parameters, that are invoked by the static methods.
My question: is why the parameterless constructor is needed?
The CSLA .NET data portal requires a parameterless constructor, because the data portal creates instances of your object.
If you don't want that constraint (and you aren't using Silverlight), I think you can use the object factory model with the data portal - in which case the data portal doesn't create your objects - you do. In that model I think (but don't know for sure) that you could skip having a default ctor.
I don't think the WCF NDCS requires a default ctor. It uses the one the compiler spits when you mark the class as [Serializable]. It might be that [DataContract] would require a default ctor.
Copyright (c) Marimer LLC