While using the
Serializable attribute is workable,
it is not ideal for service-oriented interaction between clients and services. Rather than
denoting all members in a type as serializable and therefore part of the data schema for
that type, it would be preferable to have an opt-in approach, where only members the
contract developer wants to explicitly include in the data contract are included. The
Serializable attribute forces the data type to be
serializable in order to be used as a parameter in a contract operation, and it does not
offer clean separation between the ability to use the type as a WCF operation parameter (the
"serviceness" aspect of the type) and the ability to serialize it. The attribute offers no
support for aliasing type names or members, or for mapping a new type to a predefined data
contract. The attribute operates directly on member fields and completely bypasses any
logical properties used to access those fields. It would be better to allow those properties
to add their values when accessing the fields. Finally, there is no direct support for
versioning, because the formatter supposedly captures any versioning information.
Consequently, it is difficult to deal with versioning over time.
Yet again, the WCF solution is to come up with new service-oriented opt-in attributes.
The first of these attributes is the
DataContractAttribute, defined in the
[AttributeUsage(AttributeTargets.Enum | AttributeTargets.Struct| ...