While using the
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
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 all 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| ...