Второй параметр этого специального конструктора является типом StreamingContext, содержащим информацию об источнике или пункте назначения битов. Самым информативным членом этого типа является свойство State, которое представляет значение из перечня StreamingContextStates. Значения этого перечня соответствуют базовой композиции текущего потока.
Честно говоря, если вашей задачей разработки не является низкоуровневый пользовательский сервис удаленного доступа, вам вряд ли придется обращаться к указанному перечню непосредственно. Тем не менее, ниже приводятся имена элементов перечня StreamingContextStates (подробности его описания можно найти в документации .NET Framework 2.0 SDK).
public enum StreamingContextStates {
CrossProcess,
CrossMachine,
File,
Persistence,
Remoting,
Other,
Clone,
CrossAppDomain,
All
}
Чтобы иллюстрировать возможности настройки процесса сериализации с помощью ISerializable, предположим, что у нас есть тип класса, который определяет два элемента строковых данных. Кроме того, предположим, что все символы этих строк должны сохраняться в поток в верхнем регистре, а восстанавливаться из потока – в нижнем. Чтобы учесть эти требования, вы можете реализовать ISerializable так. как показано ниже (не забудьте указать using для пространства имен System.Runtime.Serialization).
[Seriаlizable]
class MyStringData: ISerializable {
public string dataItemOne, dataItemTwo;
public MyStringData() {}
private MyStringData(SerializationInfo si, StreamingContext ctx) {
// Регидратация члена из потока.
dataItemOne = si.GetString(First_Item").ToLower();
dataItemTwo = si.GetString("dataItemTwo").ToLower();
}
void ISerializable.GetObjectData(SerializatianInfo info, StreamingContext ctx) {
// Наполнение объекта SerializationInfo
// форматированными данными.
info.AddValue("First_Item", dataItemOne.ToUpper());
info.AddValue("dataItemTwo", dataItemTwo.ToUpper());
}
}
Обратите внимание на то, что при "наполнении" типа SerializationInfo в методе GetObjectData() не требуется, чтобы элементы данных назывались одинаково с внутренними членами-переменными типа. Это может оказаться полезным тогда, когда нужно выделять данные из сохраненного формата. При этом не следует забывать о том, что для получения значений из приватного конструктора необходимо использовать имена, которые назначаются в рамках GetObjectData().
Чтобы проверить пользовательские настройки, предположим, что вы сохранили экземпляр MyStringData с помощью SoapFormatter. Заглянув в результирующий файл *.soap, вы увидите, что строковые поля в нем действительно представлены в верхнем регистре.
‹SOAP-ENV:Envelope xmlns:xsi="…"›
‹SOAP-ENV:Body›
‹a1:MyStringData id="ref-1" xmlns:a1="…"›
‹First_Item id="ref-3"›ЭTO НЕКОТОРЫЕ ДАННЫЕ.‹/First_Item›
‹dataItemTwo id="ref-4"›ЭTO НЕКОТОРЫЕ ДОПОЛНИТЕЛЬНЫЕ ДАННЫЕ‹/dataItemTwo›
‹/a1:MyStringData›
‹/SOAP-ENV:Body›
‹/SOAP-ENV:Envelope›
Настройка параметров сериализации с помощью атрибутов
Хотя реализация интерфейса ISerializable в .NET 2.0 все еще допустима, для настройки процесса сериализации теперь более предпочтительным считается определение методов, наделенных одним из целого ряда новых атрибутов, связанных с задачами сериализации (это атрибуты [OnSerializing], [OnSerialized], [OnDeserializing] и [OnDeserialized]). Использование этих атрибутов оказывается менее громоздким, чем реализация ISerializable, поскольку тогда не возникает необходимости вручную взаимодействовать с поступающим параметром SerializationInfo. Вместо этого вы получаете возможность непосредственно изменять данные состояния во время воздействия форматтера на тип.
При использовании этих атрибутов методы должны определяться так, чтобы они получали параметр StreamingContext и не возвращали ничего (в противном случае в среде выполнения генерируется соответствующее исключение). Обратите внимание на то, что не требуется учитывать все указанные атрибуты сериализации – можно учесть только те стадии сериализации, для которых следует выполнить перехват. Для примера рассмотрите новый тип [Serializable] с теми же требованиями, что и у MyStringData, но на этот раз с использованием атрибутов [OnSerializing] и [OnDeserialized].
[Serializable]
class MoreData {
public string dataItemOne, dataItemTwo;
[OnSerializing]
internal void OnSerializing(StreamingContext context) {
// Выполняется в процессе сериализации.
dataItemOne = dataItemOne.ToUpper();
dataItemTwo = dataItemTwo.ToUpper();
}
[OnDeserialized]
internal void OnDeserialized(StreamingContext, context) {
// Выполняется по завершении реконструкции объекта.
dataItemOne = dataItemOne.ToLower();
dataItemTwo = dataItemTwo.ToLower();
}
}
Если выполнись сериализацию этого нового типа, вы снова обнаружите, что данные сохраняются в верхнем регистре, а воcстанавливаются – в нижнем.
Исходный код. Проект СustomSerialization размещен в подкаталоге, соответствующем главе 17.
Поддержка версий сериализации объектов
В завершение обсуждения этой главы мы рассмотрим тему поддержки версий сериализации объектов. Чтобы понять, почему это необходимо, мы используем следующий сценарий. Предположим, что мы создали класс UserPrefs (он уже упоминался в начале главы) так, как показано ниже.
[Serializable]
class UserPrefs {
public string objVersion = "1.0";
public ConsoleColor BackgroundColor;
public ConsoleColor ForegroundColor;
public UserPrefs() {
BackgroundColor = ConsoleColor.Black;
ForegroundColor = ConsoleColor.Red;
}
}
Теперь предположим, что у нас есть приложение, в котором выполняется сериализация экземпляра этого класса с помощью BinaryFormatter.
static void Main(string[] args) {
UserPrefs up = new UserPrefs();
up.BackgroundColor = ConsoleColor.DarkBlue;
up.ForegroundColor = ConsoleColor.White;
// Сохранение экземпляра UserPrefs в файле.
BinaryFormatter binFormat = new BinaryFormatter();
Stream fStream = new FileStream(@"C:user.dat", FileMode.Create, FileAccess.Write, FileShare.None);
birFormat.Serialize(fStream, up);
fStream.Сlose();
Console.ReadLine();
}
К этому моменту экземпляр UserPrefs (версии 1.0) сохранен в C:user.dat. Но давайте добавим в определение класса UserPrefs два новых поля.
[Serializable]
class UserPrefs {
public string objVersion = "2.0";
public ConsoleColor BackgroundColor;
public ConsoleColor ForegroundColor;
// Являются новыми!
public int BeepFreq;
public string ConsoleTitle;
public UserPrefs() {
BeepFreq = 1000;
ConsoleTitle = "Моя консоль";
BackgroundColor = ConsoleColor.Black;
ForegroundColor = ConsoleColor.Red;
}
}
Теперь представьте себе, что это же приложение пытается реконструировать экземпляр сохраненного объекта UserPrefs версии 1.0 так, как показано ниже (заметьте, чтобы этот пример работал, предыдущая программная логика сериализации была удалена).
static void Main(string[] args) {
// Загрузка экземпляра UserPrefs (1.0) в память?
UserPrefs up = null;
BinaryFormatter binFormat = new BinaryFormatter();
Stream fStream = new FileStream(@"C:user.dat", FileMode.Open, FileAccess.Read, FileShare.None);
up = (UserPrefs)binFormat.Deserialize(fStream);
fStream.Close();
Console.ReadLine();
}
Вы увидите окно с информацией о следующем исключении, сгенерированном средой выполнения.
Необработанное исключение: System.Runtime.Serialization.SerializationException. Член 'BeepFreq' в классе 'VersionedObject.UserPrefs' не присутствует в сохраненном потоке и не обозначен атрибутом System.Runtime.Serialization.OptionalFieldAttribute.
Проблема в том, что оригинальный объект UserPrefs, сохраненный в C:user.dat, не сохранял два новых поля, присутствующих в обновленном определении класса (это поля BeepFreq и ConsoleTitle). Очевидно, что это настоящая проблема, поскольку для сохраняемого объекта вполне естественно эволюционировать в процессе существования.
До выхода .NET 2.0 единственной возможностью для учета того, что сохраненный объект может не иметь всех новых полей из обновленной и более поздней версии класса, была необходимость реализации ISerializable и осуществление контроля "вручную". Но с появлением .NET 2.0 новые поля могут явно обозначаться атрибутом [Optional Field] (определенным в рамках пространства имен System.Runtime.Serialization).
[Seriаlizable]
class UserPrefs {
public ConsoleColor BackgroundColor;
public ConsoleColor ForegroundColor;
// Являются новыми!
[OptionalField]
public int BeepFreq;
[OptionalField]
public string ConsoleTitle;
