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

Is there anything I might regret later, i.e. any major limitations if we choose XmlSerialization instead of DataContract? Until now, we have embraced the schema first contract design.

For example, if we want to parameter inspection, security enhancements, etc... will locking in now with XmlSerial开发者_JAVA百科ization be a problem when we try to add other WCF features?

Certain schema elements are not supported by the DataContractSerializer, such as the xs:choice element. Know that if you end up using any of those unsupported elements, you will have a very hard time switching to Data Contracts if you ever want to.

Aside from that, there's a pretty good breakdown of the DataContractSerializer vs. XmlSerializer here. Probably the most important points are:

• DataContractSerializer is usually more efficient;
• DataContractSerializer can serialize fields (XmlSerializer needs properties);
• XmlSerializer requires a public getter and setter for every serialized property (this is very annoying and can lead to some sub-optimal designs);
• XmlSerializer requires a public parameterless constructor (DataContractSerializer will actually ignore it);
• XmlSerializer is opt-out by default, whereas DataContractSerializer is opt-in;
• XmlSerializer is more likely to be able to interoperate with legacy clients (i.e. ASMX web services and other platforms);

Generally speaking, the XmlSerializer gives you a lot more control over the XML, but the DataContractSerializer gives you a lot more control over the code. If you want to use the XML serializer, you sort of have to code to its whims, whereas you can integrate Data Contracts with just about any code.