Любые ограничения XmlSerialization в WCF (в отличие от DataContract)?

Question

Есть ли что-нибудь, что я могу пожалеть позже, то есть какие-либо серьезные ограничения, если мы выберем XmlSerialization вместо DataContract? До сих пор мы рассмотрели первый контрактный проект схемы.

Например, если мы хотим проверить параметры, улучшения безопасности и т. Д. ... теперь будет заблокирована с XmlSerialization, если мы попытаемся добавить другие функции WCF?

Answer 1

Некоторые элементы схемы не поддерживаются DataContractSerializer, например, элементом xs:choice. Знайте, что если вы в конечном итоге используете любой из этих неподдерживаемых элементов, вам будет очень сложно переключиться на Data Contracts, если вы когда-либо захотите.

Кроме того, существует неплохой пробой DataContractSerializer против XmlSerializerhere. Вероятно, наиболее важными моментами являются:

• DataContractSerializer обычно более эффективен;
• DataContractSerializer может сериализовать поля (XmlSerializer нуждается в свойствах);
• XmlSerializer требует общественных геттер и сеттеров для каждой сериализованной собственности (это очень раздражает и может привести к некоторым неоптимальным конструкциям);
• XmlSerializer требует публичного конструктора без параметров (DataContractSerializer фактически проигнорирует его);
• XmlSerializer отказывается по умолчанию, тогда как DataContractSerializer - это отказ;
• XmlSerializer, скорее всего, сможет взаимодействовать с унаследованными клиентами (то есть веб-сервисами ASMX и другими платформами);

Вообще говоря, XmlSerializer дает намного больший контроль над XML, но DataContractSerializer дает намного больший контроль над кодом. Если вы хотите использовать XML-сериализатор, вам нужно кодировать свои прихоти, тогда как вы можете интегрировать Data Contracts практически с любым кодом.