Будь-клас, який може бути серіалізовані має бути позначено атрибутом SerializableAttribute. Якщо клас повинен управляти своїм процесом сериализации, можна реалізувати ISerializable інтерфейсу. Formatter Виклики GetObjectData під час сериализации і заповнює наданий SerializationInfo з усіма даними, необхідними для подання об'єкта. Formatter Створює SerializationInfo з типом об'єкта в графі. Об'єкти, які необхідно відправити проксі для самих можна використовувати FullTypeName і AssemblyName методи SerializationInfo Зміна переданих даних.
У разі успадкування класу є можливість сериализации класу, похідного від базового класу, що реалізує ISerializable. В цьому випадку похідний клас повинен викликати реалізацію базового класу GetObjectData всередині своєї реалізації GetObjectData. В іншому випадку дані з базового класу не будуть серіалізовані.
ISerializable Інтерфейс містить в собі конструктор за допомогою конструктора підпис (SerializationInfo відомості StreamingContext контексту). Під час десеріалізациі поточний конструктор викликається тільки після даних в SerializationInfo десеріалізован за допомогою модуля форматування. Як правило цей конструктор необхідно захистити, якщо клас не запечатаний.
Порядок, в якому об'єкти десеріалізуются, не може бути гарантований. Наприклад якщо один тип посилається на тип, який не був десеріалізован, виникне виключення. При створенні типів, що мають такі залежності, можна усунути проблему, реалізувавши IDeserializationCallback інтерфейс і OnDeserialization метод.
Архітектура сериализации обробляє типи об'єктів, які розширюють MarshalByRefObject таким же, як типи, що розширюють Object. Ці типи можуть бути помічені з SerializableAttribute і реалізувати ISerializable інтерфейс як будь-який інший тип об'єкту. Їх стану об'єкта будуть захоплені і збережені в потоці.
Якщо ці типи використовуються через System.Runtime.Remoting. інфраструктура віддаленого взаємодії надає сурогат, який вивантажує типовий сериализации і замість цього серіалізуются проксі MarshalByRefObject. Сурогат - це помічник, який знає спосіб сериализации і десеріалізациі об'єктів певного типу. Проксі-сервер, невидимою для користувача в більшості випадків буде мати тип ObjRef.
В рамках загального конструктивного шаблону не прийнято позначати клас за допомогою Серіалізуемое атрибута і розширювати MarshalByRefObject. Розробникам необхідно ретельно продумувати можливі сценарії сериализации і віддаленого взаємодії при об'єднанні цих двох характеристик. Є прикладом, де це може застосовуватися з MemoryStream. Хоча базовий клас MemoryStream (Stream) розширює з MarshalByRefObject. є можливість запису стану MemoryStream і відновити її на будуть. Таким чином, можливо, слід серіалізовать стан цього потоку в базу даних і відновити його в більш пізній момент часу. Однак при використанні за допомогою віддаленого взаємодії, об'єкт цього типу б проксі.
Додаткові відомості про сериализации класів, які розширюють MarshalByRefObject. в розділі RemotingSurrogateSelector. Додаткові відомості про реалізацію ISerializable. в розділі для користувача сериализация.
Нотатки про реалізацію:
Реалізуйте цей інтерфейс, щоб дозволити об'єкту взяти участь в сериализации і десеріалізациі.