Введение в WCF 4.0. Контракты данных и версионирование контрактов

Очень часто в методы сервисов мы передаем более комплексные объекты. Как было уже сказанно — отличная вещи WCF сервисов — это то , что их могут использовать программы написанные на разных технологиях. Если с обычными типами, вроде int, string и т.д проблем нету ни в одной из современных технологий, то с комплексными дела состоят совсем по другому.
Контракты данных — это такая договеренность между сервисом и клиентом — по которой клиент точно знает структуру объекта которая прийдет или передасться WCF сервису. Сосбветнно именно благодаря контракту данных .Net знает как серилизовать и десерелизовать объект в XML.

Теперь давайте попробуем создать свой DataContract. Для этого давайте добавим отдельную сборку, где у нас будет лежать наши контракты данных. В ней добавим небольшой класс, приблизительно такого значения:

    /// <summary>
    /// this is a complex object which will be sent to WCF Service
    /// </summary>
    [DataContract]
    public class ComplexObject
    {
        /// <summary>
        /// Gets or sets the string value.
        /// </summary>
        /// <value>The string value.</value>
        [DataMember]
        public string StringValue { get; set; }

        /// <summary>
        /// Gets or sets the int value.
        /// </summary>
        /// <value>The int value.</value>
        [DataMember]
        public int IntValue { get; set; }

        /// <summary>
        /// Gets or sets the float value.
        /// </summary>
        /// <value>The float value.</value>
        [DataMember]
        public float FloatValue { get; set; }

        /// <summary>
        /// Gets or sets a value indicating whether [bool value].
        /// </summary>
        /// <value><c>true</c> if [bool value]; otherwise, <c>false</c>.</value>
        [DataMember]
        public bool BoolValue { get; set; }
    }

Как видим над контракт содержит себе свойства разных типов. Чтобы компилятор знал что это именно контракт данных — мы это явно указываем с помошюь аттрибута DataContract, чтобы показать свойства этого объекта мы указываем это с помощью аттрибута [DataMember].

Теперь мы можем запросто создавать метод в нашем сервисе который будет принимать как параметр объект типа ComplexObject.

Версионирование контрактов.
В одном из прошлых постов я говорил, что интерфейсы контрактов не должны меняться. Собственно так оно и есть:)
Давайте рассмотрим несколько простых правил которые помогут нам избежать ошибок.

Контракты сервисов:
1. Вы можете добавлять методы в любой момент — собственно это правильно, потому как старые методы не меняются, и WSDL сгенерированный для существующих методов не поменятеся.
2. Нельзя удалять существующие методы — так как WSDL уже был сгенерен — вы можете вызвать несуществующий метод на сервисе. Для того чтобы такое избежать нужно или не удалять метод или же перегенерить WSDL, но это приведет к рекомпиляции клиента.
3. Типы которые передаются в метод могут меняться, но должны быть совместимы.

Контракты данных:
Помните именно по этим контрактом система знает как серелизовать и десерелизовать объекты которые отсылаются на сервер или клиенту. Если возникла нужда поменять контракт данных, воспользуйтесь этими правилами:
1. Никакого наследования! Если нужно поменять контракт данных — лучше создайте новый.
2. Если имя класса или свойства в контракте данных поменялось — можна создать корректную версию с помощью аттрибутов, например:
[DataMember()]
private DateTime PickupDate { get; set; }

и

[DataMember(Name = «PickupDate»)]
private DateTime FromDate { get; set; }

в результате выдадут один и тот же контракт.
3. Нельзя менять тип свойства контракта.
4. Нельзя менять порядок свойств.
5. Нельзя удалять свойства.
6. Вы можете добавлять новые свойства, главное помнить что это менять порядок серелизации.

Следуюя этим простым правилами, вы сможете менять же созщданные сервиса, не меняя при этом клиенты.