Подтвердить что ты не робот

Каковы преимущества использования [DataContract], а не [Serializable] в WCF

Любое преимущество использования DataContract?

4b9b3361

ОТВЕТЫ

Ответ 1

Посмотрите отличный сравнение XmlSerializer и DataContractSerializer в блоге Дэна Ригсби.

Некоторые точки в пользу DataContractSerializer:

  • примерно на 10% быстрее, чем XmlSerializer
  • будет сериализовать что-либо, украшенное [DataMember] - даже если оно не public видно
  • не будет сериализовать что-либо , если только вы не указали это ( "opt-in" )
  • вы можете определить порядок, в котором элементы сериализуются с использованием атрибута Order= на [DataMember]
  • не требует конструктора без параметров для десериализации

Ответ 2

Есть еще один вопрос, на который еще не ответили остальные: Что делать, если вы используете [Serializable], но используете DataContractSerializer для сериализации этого типа? Разве это не отличается от сериализации типа [DataContract] с помощью DataContractSerializer?

Ответ: это не имеет никакого значения! Причина в том, что когда вы передаете любой поддерживаемый тип в DataContractSerializer, в первом сериализации или эпизоде ​​десериализации, он "клонит" тип во внутреннюю структуру, которая содержит всю информацию о членах типа и т.д. Затем он использует кешированный внутренняя структура (сохраненная с использованием динамического ИЛ) для последующих серийных эпизодов, никогда не возвращаясь к исходному типу.

Кроме того, если вы сравниваете сериализацию [Serializable] [Serializable] типов и XmlSerializer сериализации тех же типов, вы обнаружите, что сериализация DataContract будет экспоненциально быстрее. Немного об этом видно в приведенной ниже таблице сравнения производительности: http://msdn.microsoft.com/en-us/library/bb310550.aspx

Ответ 3

Вы также можете иметь в виду, что DataContract более ориентирован на потребителя, чем XmlSerializer.

В то время как XmlSerializer имеет чисто технический размер ( "как преобразовать этот объект в XML" ), DataContract является представлением бизнес-концепции с открытым доступом.

Как таковой DataContract действует как напоминание о том, что каждое изменение, которое вы делаете в своем классе, будет влиять на потребителей и что вы неявно связаны этим контрактом. Концептуально, DataContract является центральным элементом вашей архитектуры обслуживания, XmlSerializer - это всего лишь помощник.

Ответ 4

Основные проблемы с XmlSerializer для сериализации .NET-типов в XML

  • Только публичные поля или свойства типов .NET могут быть переведены в XML
  • Только классы, реализующие интерфейс IEnumerable
  • Классы, реализующие интерфейс IDictionary, такие как таблица Hash, не могут быть сериализованы Важное различие между DataContractSerializer и XMLSerializer

Практическое преимущество конструкции DataContractSerializer - лучшая производительность по сравнению с Xmlserializer.

  • Сериализация XML не указывает, какие поля или свойства этого типа сериализуются в XML, тогда как DataCotractSerializer
  • Явно показывает, какие поля или свойства сериализуются в XML
  • DataContractSerializer может переводить HashTable в XML

Ответ 5

Хотя этот вопрос довольно старый, но я подведу итог своему пониманию:

1) Datacontract дает вам гибкость сериализации определенных членов или полей с использованием атрибута (DataMember). 2) Вы можете решить с помощью DataContract порядок, в котором ваши объекты будут сериализованы.

Помимо очевидных вещей, поскольку DataContract сериализует ваши публичные элементы, тогда как Serializable по умолчанию будет сериализовать ваши поля.

Ответ 6

Нет никакой реальной базы для сравнения, если все, что вы делаете, сериализуется и десериализуется из XML, кроме синтаксических различий и второстепенных функций. Самое сильное преимущество DataContract над Serializable - то, что, по-видимому, все пропускают, заключается в том, что контракты данных не специфичны для XML.

Работая с контрактами данных, существует только две логические конструкции: контракты данных и члены данных (члены контракта данных). В договоре с данными таких вещей нет как "элементы" или "элементы xml".

Теоретически сериализация на основе данных на основе данных позволяет представлять структуру объекта в любом формате обмена данными, хотя в настоящее время в платформе .NET доступны только XML и JSON-сериализация/десериализация. Однако, безусловно, возможно создать сериализатор, чем работать с, скажем, RDF, и я подозреваю, что там есть дополнительные сериализаторы.

Рассмотрим следующую простую архитектуру:

С#

[DataContract]
class Company
{
    [DataMember]
    public string Name { get; set }

    [DataMember]
    public Person[] People { get; set }
}

[DataContract]
class Person
{
    [DataMember]
    public string FirstName { get; set; }

    [DataMember]
    public string LastName { get; set; }
}

Этот контракт не является специфичным для XML. Вы не указали ничего связанного с XML. Вы можете сериализовать экземпляр вышеуказанной архитектуры либо в XML:

XML

<Company>
  <Name>...</Name>
  <People>
    <Person>
      <FirstName>James</FirstName>
      <LastName>Sunderland</LastName>
    </Person>
    ...
  </People>
</Company>

... или в JSON:

JSON

{
    "Company": {
        "Name": "...",
        "People": [
            {
                "FirstName": "James",
                "LastName": "Sunderland"
            },
            ...
        ]
    }
}

... или в любой произвольный формат обмена данными, если у вас есть сериализатор для этого формата.

Это очень мощный и гибкий, особенно если у вас есть веб-сервис, который потребляется несколькими типами клиентов и одноранговых узлов, или если группа пользователей вашего веб-сервиса будет расширена в будущем:

  • JSON проще сериализовать/десериализовать в JavaScript и PHP-серверах (или любом динамическом языке),
  • XML более простой для сериализации/десериализации в WCF-клиентах.

Если вы не хотите ограничивать себя XML как единственным форматом обмена данными в архитектуре приложения, я рекомендую вам пойти с DataContract. В противном случае Serializable немного полезнее только для XML.