Віддалене взаємодія .NET
При розробці нових типів необхідно вибрати технології, які повинні підтримувати ці типи (якщо є). Нижче наведено кілька порад, які допоможуть зробити цей вибір і описано, як реалізувати таку підтримку. Ці рекомендації не слід сприймати як вказівку для вибору технології сериализации для використання в реалізації програми або бібліотеки. Вони не пов'язані безпосередньо з розробкою API, тому їх повний опис не може бути приведено в рамках даного розділу.
Розробка нових типів ПОВИННА проводитися з урахуванням сериализации.
Її необхідно брати до уваги при розробці всіх типів, оскільки програмою може знадобитися зберегти або надіслати примірника типу.
Правильний вибір сериализации для підтримки
Будь-який тип може як підтримувати одну або кілька технологій сериализации, так і не підтримуватиме жодної.
Якщо екземпляри типу необхідно зберігати або використовувати в веб-службах, РЕКОМЕНДУЄТЬСЯ вибрати підтримку сериализации контракту даних.
Якщо є потреба у додатковому контроль над XML-форматом, створюваним при серіалізациі типу, РЕКОМЕНДУЄТЬСЯ вибрати підтримку XML-сериализации замість сериализации контракту даних або на додаток до неї.
Підтримка цієї технології може знадобитися в певних сценаріях взаємодій, де необхідне використання конструкцій XML, підтримуються при серіалізациі контракту даних, наприклад при створенні XML-атрибута.
Якщо екземпляри типу повинні передаватися за межі кордонів архітектури віддаленого взаємодії .NET, РЕКОМЕНДУЄТЬСЯ вибрати підтримку сериализации середовища виконання.
НЕ рекомендується вибирати сериализацию середовища виконання або XML-сериализацию для використання загальних переваг, які забезпечуються збереженням. Замість цього рекомендується використовувати сериализацию контракту даних
Підтримка сериализации контракту даних
Типи можуть підтримувати сериализацию контракту даних при застосуванні DataContractAttribute до типу і застосуванні DataMemberAttribute до елементів (полів і властивостями) типу.
РЕКОМЕНДУЄТЬСЯ помітити елементи даних типу як відкриті, якщо тип може бути використаний в середовищі з частковим довірою. У середовищі з повною довірою серіалізатор контрактів даних можуть виконувати сериализацию і десеріалізацію закритих типів і елементів, але в середовищі з частковим довірою ці операції можуть виконуватися тільки для відкритих елементів.
НЕОБХІДНО реалізувати метод зчитування і метод завдання для всіх властивостей, що мають атрибут Data-MemberAttribute. При використанні серіалізатор контрактів даних тип вважається серіалізуемим тільки при наявності обох методів - зчитування і завдання. Якщо тип не буде використовуватися в середовищі з частковим довірою, то один або кілька методів доступу до властивості можуть бути закритими.
РЕКОМЕНДУЄТЬСЯ для ініціалізації десеріалізованних примірників використовувати зворотні виклики сериализации.
При десеріалізациі об'єктів конструктори не викликаються. Отже, будь-яка логіка, яка виконується при нормальному побудові, повинна бути реалізована як один з зворотних викликів сериализации.
Атрибут OnDeserializedAttribute є найбільш часто використовуваних атрибутом зворотного виклику. Крім того, в сімейство входять атрибути OnDeserializingAttribute. OnSeralizingAttribute і OnSerializedAttribute. Їх можна використовувати для позначки зворотних викликів, які виконуються перед десеріалізацію, перед сериализацией і після сериализации відповідно.
РЕКОМЕНДУЄТЬСЯ використовувати KnownTypeAttribute для вказівки конкретних типів, які повинні використовуватися при десеріалізациі більш складного графа об'єкта.
Наприклад, якщо тип десеріалізуемого елемента даних представлений абстрактним класом, то серіалізатор будуть потрібні відомості про відомого типі. щоб вибрати конкретний тип для створення екземплярів і присвоювання елементу. Якщо відомий тип не вказано, то його необхідно явно передати серіалізатор (це можна зробити, передавши відомі типи конструктору серіалізатор) або вказати у файлі конфігурації.
У тих випадках, коли список відомих типів статично невідомий (при компіляції класу Person), KnownTypeAttribute також може вказувати на метод, який повертає список відомих типів під час виконання.
При створенні і зміні Серіалізуемое типів РЕКОМЕНДУЄТЬСЯ забезпечувати пряму і зворотну сумісність.
Необхідно пам'ятати, що Серіалізуемое потоки майбутніх версій типу можуть бути десеріалізовани в поточну версію типу і навпаки. Необхідно враховувати, що елементи даних, навіть закриті і внутрішні, не можуть змінювати свої імена, типи і навіть свій порядок в майбутніх версіях типів, якщо не вжито спеціальних заходів для збереження контракту за допомогою явних параметрів в його атрибутах. При зміні Серіалізуемое типів перевірте сумісність сериализации. Спробуйте десеріалізовать нову версію в попередню і навпаки.
РЕКОМЕНДУЄТЬСЯ реалізувати інтерфейс IExtensibleDataObject. Це дасть можливість забезпечити цикл обробки значень між різними версіями типу.
Інтерфейс дає серіалізатор гарантію відсутності втрат даних при виконанні циклів обробки значень. Властивість ExtensionData зберігає всі дані з майбутньої версії типу, невідомі в поточній версії. Якщо поточна версія потім серіалізуются і десеріалізуется в більш пізню, то додаткові дані будуть доступні в серіалізовані потоці завдяки значенню властивості ExtensionData.
Підтримка XML-сериализации
Серіалізация контрактів даних є основною (задається за замовчуванням) технологією сериализации в .NET Framework, однак існують сценарії сериализации, які ця технологія не підтримує. Наприклад, вона не забезпечує повний контроль над формою XML-коду, створюваного або використовуваного серіалізатор. Якщо необхідний такий високий рівень контролю, використовуйте XML-сериализацию. розробивши типи для підтримки цієї технології сериализации.
Необхідно УНИКАТИ розробки типів спеціально для XML-сериализации, за винятком випадків, коли необхідний контроль над формою створюваного XML-коду. Ця технологія сериализации була замінена сериализацией контракту даних, описаної в попередньому розділі.
Іншими словами, не слід застосовувати атрибути з простору імен System.Runtime.Serialization до нових типів, якщо тільки цей тип не планується використовувати з XML-сериализацией. У наступному прикладі описано використання System.Xml.Serialization для управління формою створюваного XML-коду.
РЕКОМЕНДУЄТЬСЯ використовувати реалізацію інтерфейсу IXmlSerializable. якщо необхідний більш високий рівень контролю над формою Серіалізуемое XML-коду, ніж той, який забезпечується при застосуванні атрибутів XML-сериализации. Два методу інтерфейсу, ReadXml і WriteXml. забезпечують повний контроль над серіалізуемим XML-потоком. При цьому забезпечується можливість контролю над схемою XML, яка створюється для типу шляхом застосування атрибута XmlSchemaProviderAttribute.
Підтримка сериализации під час виконання
Серіалізация під час виконання являє собою технологію, використовувану при віддаленому взаємодії .NET. Якщо планується передача типів з використанням віддаленого взаємодії .NET, то необхідно переконатися, що вони підтримують сериализацию під час виконання.
Базова підтримка сериализации під час виконання може бути забезпечена за допомогою атрибута SerializableAttribute. При більш складних сценаріях виконується реалізація простого шаблону сериализации під час виконання (реалізація ISerializable і забезпечення конструктора сериализации).
РЕКОМЕНДУЄТЬСЯ забезпечити для типів підтримку сериализации під час виконання, якщо типи будуть використовуватися при віддаленому взаємодії .NET. Наприклад, в просторі імен System.AddIn використовується віддалене взаємодія .NET і тому всі типи, що передаються між надбудовами System.AddIn. повинні підтримувати сериализацию під час виконання.