catch (SerializationException е) {

Console.WriteLine( А serialization exception has been thrown! ); Console.WriteLine( Сгенерировано исключение сериализации! ); Console.WriteLine(е.Message);

catch (lOException e) {

Console.WriteLine( An 10 exception has been thrown! ); ошибка ввода-вывода Console.WriteLine(e.ToString());

Console.ReadKey();

5. Запустите приложение. Результат должен получиться подобным показанному на рис. 24.9.

Рис. 24.9. Исключение во время работы приложения ObjectStore

6. Модифицируйте код Product.cs следующим образом:

namespace ObjectStore {

[Serializable] public class Product

7. Запустите приложение снова. Результат представлен на рис. 24.10

Рис. 24.10. Результат работы приложения ObjectStore

8, Откройте файл Products .bin в Notepad. Содержимое этого файла показано на рис. 24.11.

. Productt bm НШ%>аа

т ЫШ ИхтгЛ УЛвт Нвф ~

>у h BObjecTStore, version-!.0.0.0, --

Culture-neutral, РиЬ11скеутокеп-пи11

I System.collections.Generic.Li St 1[[objectStore.Product. ObiectStore, verslon-1.0.0.0. Culture-neutral, Publ 1CK eyTotr en-nul 1 ] 11 - 11 ws i s 1 zeii ver s 1 orw .lobjectstore. Product [], x i i i .i >

jiObjectstore. Product, > \ - и

ObjectStore.Product ,IdJNdmePrIce -, - Spiky Pung

M I i , -0 iGloop Galloop soup 9* - i

Hat Sauce (ад

Рис. 24.11. Содержимое файла Products. bin

Описание полученных результатов

в этом примере создается коллекция объектов Product, которая сохраняется на диске, а затем перезагружается оттуда. При первом запуске приложения, однако, было сгенерировано исключение, потому что объект Product не был помечен как сериали-зуемый (serializable).

.NET Framework требует помечать объекты как сериализуемые, чтобы можно было выполнять их сериализацию. На то есть несколько причин, включая следующие.

□ Некоторые объекты не очень хорошо сериализуются. Они могут требовать ссылок на локальные данные, которые, например, существуют только до тех пор, пока находятся в памяти.

а Некоторые объекты могут содержать важные данные, которые не нужно сохранять небезопасным способом или передавать другому процессу

Как показано в примере, пометить объект сериализуемым очень просто - для этого применяется атрибут Serializable:

namespace ObjectStore

[Serializable] public class Product {

Обратите внимание, что этот атрибут не наследуется производными классами. Он должен быть применен к каждому классу, который планируется подвергнуть сериализации. Также следует отметить, что класс List<T>, использованный для генерации коллекции объектов Product, имеет этот атрибут; в противном случае применение его к Product не позволит сделать коллекцию сериализуемой.

Когда коллекция products успешно сериализована и десериализована (со второй попытки), становится очевидным другой важный факт. При десериализации восстанавливаются только поля Id, Name и Price. Это связано с использованием другого атрибута, а именно - NonSearialized:

[NonSerialized] string Notes;

Любой член класса может быть помечен этим атрибутом, и тогда он не будет сохраняться вместе с другими членами. Это может быть полезно, если, например, только одно поле или свойство содержит ответственные данные.

Вы также видели результирующие сохраненные данные в этом примере. Некоторые данные здесь читабельны для человека; это может быть нежелательно или неожиданно. Класс BinaryFormatter не предпринимает серьезных попыток защитить данные от посторонних глаз. Конечно, поскольку вы используете потоки, относительно легко перехватить данные при сохранении их на диске или загрузке приложением и применить собственный маскирующий или шифрующий алгоритм. То же касается сжатия - применяя технику из предыдущего раздела, вы довольно легко можете сжать данные объекта при сохранении на диск.

Тема сериализации включает еще многое, но изложенной информации достаточно, чтобы заложить основу. Одной из наиболее развитых техник, которые имеет смысл изучить, является специальная сериализация с применением интерфейса ISerializable, который позволяет точно настраивать, какие именно данные подлежат сериализации. Это может оказаться важным, например, при обновлении клас-

сов в последующем выпуске. Изменение перечня членов, подлежащих сериализации, может привести к тому, что сохраненные предыдущей версией данные окажутся нечитабельными, если только вы не предусмотрите собственную логику сохранения и извлечения данных.

Мониторинг структуры файла

Иногда приложения должны делать нечто большее, чем просто запись файлов в файловую систему. Например, может быть важно знать, когда модифицируются файлы или каталоги. .NET Framework облегчает задачу создания таких приложений, которые делают это.

Класс, помогающий в этом, называется FileStreamWatcher. Он предоставляет несколько событий, которые приложение может перехватить. В результате приложение может реагировать на события файловой системы.

Базовая процедура использования FileStreamWatcher проста. Сначала вы должны установить несколько свойств, которые укажут, где нужно выполнять мониторинг, что отслеживать и когда должно возникнуть событие, которое приложение обработает. Затем вы предоставляете ему адреса обработчиков событий, чтобы они вызывались при наступлении какого-то существенного события. И, наконец, вы запускаете его и ждете событий.

Свойства, которые должны быть установлены перед включением объекта FileStreamWatcher в работу, перечислены в табл. 24.10.

Таблица 24.10. Свойства, которые должны быть установлены для объекта FileStreamWatcher

Свойство Описание

Path Должно быть установлено в местоположение или каталог, который нужно

отслеживать

NotifyFiiter Комбинация значений перечисления NotifyFiiters, специфицирующих, что именно нужно отслеживать в файлах, подверженных мониторингу. Это представляет свойства файла или папки, подверженной мониторингу. Если любое из указанных свойств изменяется, инициируется событие. Возможные значения перечисления - Attributes, CreationTime, DirectoryName, FileName, LastAccess, LastWrite, Security и Size. Обратите внимание, что их можно комбинировать двоичной операцией ИЛИ

Filter Фильтр, специфицирующий файлы, которые нужно подвергать мониторингу,

например, *. txt

Установив все это, вы должны написать обработчики четырех событий: Changed, Created, Deleted и Renamed. Как было показано в главе 13, для этого нужно всего лишь разработать собственный метод и назначить его событию объекта. Назначая собственные обработчики этим методам, вы обеспечиваете возможность их вызова при возникновении события. Каждое событие инициируется, когда модифицируется файл или каталог, соответствующий Path, NotifyFiiter и Filter.

Установив названные свойства и события, установите свойство EnableRaisingEvents в true, чтобы запустить мониторинг В следующем практическом занятии применяется FileSystemWatcher в простом клиентском приложении для слежения за выбранным каталогом.