Have Geek Brain

Any XmlSerialization limitations in WCF (as opposed to DataContract)?

Is there anything I might regret later, i.e. Any serious limitations if we choose XmlSerialization instead of DataContract? So far we have reviewed the first contractual design of the scheme.

For example, if we want to validate options, security enhancements, etc ... will now block with XmlSerialization if we try to add other WCF functionality?

+2


source to share


1 answer


Some schematic elements are not supported DataContractSerializer

, such as an element xs:choice

. Be aware that if you end up using any of these unsupported elements, it will be very difficult for you to switch to Data Contracts if you ever want to.

Also, there is a pretty good breakdown DataContractSerializer

vs. XmlSerializer

here . Probably the most important points:



  • DataContractSerializer

    usually more effective;
  • DataContractSerializer

    can serialize fields ( XmlSerializer

    needs properties);
  • XmlSerializer

    a set of public getters is required and for each serialized property (this is very annoying and can lead to some non-optimal projects);
  • XmlSerializer

    a public constructor with no parameters is required ( DataContractSerializer

    actually ignores it);
  • XmlSerializer

    disabled by default, when it DataContractSerializer

    is a failure;
  • XmlSerializer

    is likely to be able to interact with legacy clients (i.e. ASMX web services and other platforms);

Generally speaking, XmlSerializer

it gives you a lot more control over XML, but DataContractSerializer

it gives you a lot more control over your code. If you want to use an XML serializer you have to code your whims, whereas you can integrate Data Contracts with just about any code.

+4


source






More articles:


All Articles