Какие-нибудь ограничения XmlSerialization в WCF (в отличие от DataContract)? - PullRequest
Новая
       34

Какие-нибудь ограничения XmlSerialization в WCF (в отличие от DataContract)?

2 голосов
/ 12 апреля 2010

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

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

1 Ответ

4 голосов
/ 12 апреля 2010

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

Помимо этого, есть довольно хороший разбив DataContractSerializer против XmlSerializer здесь . Вероятно, наиболее важные моменты:

  • DataContractSerializer обычно более эффективен;
  • DataContractSerializer может сериализовать поля (XmlSerializer нужны свойства);
  • XmlSerializer требует public getter и setter для каждого сериализованного свойства (это очень раздражает и может привести к некоторым неоптимальным проектам);
  • XmlSerializer требуется открытый конструктор без параметров (DataContractSerializer будет фактически игнорировать его);
  • XmlSerializer по умолчанию отключено, тогда как DataContractSerializer является отказом;
  • XmlSerializer с большей вероятностью сможет взаимодействовать с устаревшими клиентами (т. Е. Веб-сервисами ASMX и другими платформами);

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

...