Язык программирования С# 2005 и платформа .NET 2.0.

Пространство System.IO предлагает четыре типа, позволяющие как обработку отдельных файлов, так и взаимодействие со структурой каталогов машины. Первые два из этих типов – Directory и File – с помощью различных статических членов позволяют выполнение операций создания, удаления, копирования и перемещения файлов. Родственные типы FileInfo и DirectoryInfo предлагают аналогичные возможности в виде методов экземпляра (который, таким образом, необходимо будет создать). На рис. 16.1 показана схема зависимости типов, связанных с обработкой каталогов и файлов. Обратите внимание на то, что типы Directory и File расширяют непосредственно System.Object, в то время как DirectoryInfo и FileInfo получаются из абстрактного типа FileSystemInfo.

Рис. 16.1. Типы, обеспечивающие работу с каталогами и файлами

Вообще говоря, FileInfо и DirectoryInfо являются лучшим выбором для рекурсивных операций (таких как, например, составление перечня всех подкаталогов с данным корнем), поскольку члены классов Directory и File обычно возвращает строковые значения, а не строго типизированные объекты.

Абстрактный базовый класс FileSystemInfo

Типы DirectoryInfo и FileInfo во многом наследуют свое поведение от абстрактного базового класса FileSystemInfo. По большей части члены класса FileSystemInfo используются для получения общих характеристик (таких как, например, время создания, различные атрибуты и т.д.) соответствующего файла иди каталога. В табл. 16.2 описаны свойства FileSystemInfo, представляющие наибольший интерес.

Таблица 16.2. Свойства FileSystemInfo

Тип FileSystemInfo определяет также метод Delete(). Этот метод реализуется производными типами для удаления данного файла или каталога с жесткого диска. Кроме того, перед получением информации атрибута может вызываться Refresh(), чтобы гарантировать то, что информация о текущем файле (или каталоге) не будет устаревшей.

Первым из рассматриваемых в нашем обсуждении типов, связанных с реализацией ввода-вывода и допускающих создание экземпляров, будет класс DirectoryInfo. Этот класс предлагает набор членов, используемых для создания, перемещения, удаления и перечисления каталогов и подкаталогов. Кроме функциональных возможностей, обеспеченных базовым классом (FileSystemInfo), класс DirectoryInfo предлагает и свои члены, описанные в табл. 16.3.

Таблица 16.3. Основные члены типа DirectoryInfo

Мы начнем работу с типом DirectoryInfo с попытки указать конкретный путь каталога для использования в качестве параметра конструктора. Чтобы получить доступ к текущему каталогу приложения (т.е. к каталогу приложения, выполняющегося в данный момент), используйте обозначение ".". Вот подходящие примеры.

// Привязка к текущему каталогу приложения.

DirectoryInfo dir1 = new DirectoryInfo(".");

// Привязка к C:\Windows с помощью строки,

// для которой указано "дословное" применение.

DirectoryInfo dir2 = new DirectoryInfo(@"C:\Windows");

Во втором примере предполагается, что передаваемый конструктору путь (путь C:\Windows) уже существует на данной физической машине. Если вы попытаетесь взаимодействовать с несуществующим каталогом, будет сгенерировано исключение System.IO.DirectoryNotFoundException (каталог не найден). Поэтому если вы укажете каталог, который еще не создан, то перед его использованием вам придется сначала вызвать метод Create().

// Привязка к несуществующему каталогу с последующим его созданием.

DirectoryInfo dir3 = new DirectoryInfo(@"C:\Window\Testing"); 

dir3.Create();

После создания объекта DirectoryInfo вы можете исследовать содержимое соответствующего каталога с помощью свойств, унаследованных от FileSystemInfo. Например, следующий класс создает новый объект DirectoryInfo, связанный с C:\Windows (при необходимости измените этот путь в соответствии с установками системы на вашей машине) и отображающий ряд интересных статистических данных об указанном каталоге (рис. 16.2).

class Program {

 static void Main(string[] args) {

  Console.WriteLine("***** Забавы с Directory(Info) *****\n");

  DirectoryInfo dir = new DirectoryInfo(@"C:\Windows");

  // Информация о каталоге.

  Console.WriteLine("***** Информация о каталоге *****");

  Console.WriteLine("Полное имя: {0} ", dir.FullName);

 Console.WriteLine("Имя: {0} ", dir.Name);

 Console.WriteLine("Родитель: {0} ", dir.Parent);

 Console.WriteLine("Создан: {0} ", dir.CreationTime);

 Console.WriteLine("Атрибуты: {0} ", dir.Attributes);

 Console.WriteLine("Корневой каталог: {0}", dir.Root);

 Console.WriteLine("********************************\n");

 }

}

Рис. 16.2. Информация о каталоге Windows

Перечень FileAttributes

Свойство Attributes, предоставленное объектом FileSystemInfо, обеспечивает получение различной информации о текущем каталоге или файле, и вся она содержится в перечне FileAttributes. Имена полей этого перечня говорят сами за себя, но некоторые менее очевидные имена здесь сопровождаются комментариями (подробности вы найдете в документации .NET Framework 2.0 SDK).

public enum FileAttributes {

 ReadOnly,

 Hidden,

 // Файл, являющийся частью операционной системы или используемый

 // исключительно операционной системой.

 System,

 Directory,

 Archive,

 // Это имя зарезервировано для использования в будущем.

 Device,

 // Файл является 'нормальным' (если не имеет других

 // установленных атрибутов),

 Normal,

 Temporary,

 // Разреженные файлы обычно являются большими файлами,

 // данные которых по большей части – нули.

 SparseFile,

 // Блок пользовательских данных, связанных с файлом или каталогом.

 ReparsePoint,

 Compressed,

 Offline,

 // Файл, который не будет индексирован службой индексации

 // содержимого операционной системы.

 NotContentIndexed,

 Encrypted

}

Перечисление файлов с помощью DirectoryInfo

Вдобавок к получению базовой информации о существующем каталоге, вы можете добавить в пример несколько вызовов методов типа DirectoryInfo. Сначала используем метод GetFiles(), чтобы получить информацию обо всех файлах *.bmp, размещенных каталоге C:\Windows. Этот метод возвращает массив типов FileInfo, каждый из которых сообщает подробности о конкретном файле (подробности о самом типе FileInfo будут представлены в этой главе немного позже).

class Program {

 static void Main(string[] args) {

  Console.WriteLine("***** Забавы с Directory(Info) *****\n");

  DirectoryInfo dir = new DireetoryInfо(@"C:\Windows");

  // Получение всех файлов с расширением bmp.

  FileInfo[] bitmapFiles = dir.GetFiles("*.bmp");

 // Сколько их всего?

 Console.WriteLine("Найдено {0} файлов *.bmp\n", bitmapFiles.Length);

  // Вывод информации о файлах.

 foreach (FileInfo f in bitmapFiles) {

  Console.WriteLine("***************************\n");

  Console.WriteLine("Имя: {0} ", f.Name);

  Console.WriteLine("Размер: {0} ", f.Length);

  Console.WriteLine("Создан: {0} ", f.CreationTime);

  Console.WriteLine("Атрибуты: {0} ", f.Attributes);

   Console.WriteLine("***************************\n");

  }

 }

}

Запустив это приложение, вы увидите список, подобный показанному на рис. 16.3 (ваши результаты могут быть другими!).

Рис. 16.3. Информация о файлах с точечными изображениями

Создание подкаталогов с помощью DirectoryInfo

Вы можете программно расширить структуру каталога, используя метод DirectoryInfo.CreateSubdirectory(). Этот метод с помощью одного обращения к функции позволяет создать как один подкаталог, так и множество вложенных подкаталогов. Для примера рассмотрите следующий блок программного кода, расширяющий структуру каталога C:\Windows путем создания нескольких пользовательских подкаталогов.

class Program {

 static void Main(string[] args) {

  Console.WriteLine("***** Забавы с Directory(Info) *****\n");

 DirectoryInfo dir = new DirectoryInfo(@"C:\Windows");

  …

  // Создание \MyFoo в исходном каталоге.

  dir.CreateSubdirectory("MyFoo");

  // Создание \MyBar\MyQaaz в исходном каталоге

  dir.CreateSubdirectory(@"MyBar\MyQaaz");

 }

}

Если теперь проверить каталог Windows в окне программы Проводник, вы увидите там новые подкаталоги (рис. 16.4).

Рис. 16.4. Создание подкаталогов

Хотя вы и не обязаны использовать возвращаемое значение метода CreateSubdirectory(), полезно знать, что в случае успешного выполнения тип DirectoryInfo возвращает созданный элемент.

// CreateSubdirectory() возвращает объект DirectoryInfo, 

// представляющий новый элемент.

DirectoryInfo d = dir.CreateSubdirectory("MyFoo"); 

Console.WriteLine("Создан: {0} ", d.FullName);

d = dir.CreateSubdirectory(@"MyBar\MyQaaz"); 

Console.WriteLine("Создан: {0} ", d.FullName);

Как показывает пример MyDirectoryApp, класс FileInfo позволяет получить подробные сведения о файлах, имеющихся на вашем жестком диске (время создания, размер, атрибуты и т.д.), а также помогает создавать, копировать, перемещать и уничтожать файлы. Вдобавок к набору функциональных возможностей, унаследованных от FileSystemInfо, класс FileInfo имеет свои уникальные члены, и некоторые из них описаны в табл. 16.4.

Таблица 16.4. Наиболее важные элементы FileInfo

Важно понимать, что большинство членов класса FileInfo возвращает специальный объект ввода-вывода (FileStream, StreamWriter и т.д.), который позволит начать чтение или запись данных в соответствующем файле в самых разных форматах. Мы исследуем указанные типы чуть позже, а пока что давайте рассмотрим различные способы получения дескриптора файла с помощью типа класса FileInfo.

Метод FileInfо.Create()

Первая возможность создания дескриптора файла обеспечивается методом FileInfo.Create().

public class Program {

 static void Main(string[] args) {

  // Создание нового файла на диске C.

  FileInfo f = new FileInfо(@"C:\Test.dat");

 FileStream fs = f.Create();

  // Использование объекта FileStream.…

 // Закрытие файлового потока.

  fs.Close();

 }

}

Обратите внимание на то, что метод FileInfo.Create() возвращает тип FileStream, который, в свою очередь, предлагает набор синхронных и асинхронных операций записи/чтения для соответствующего файла. Объект FileStream, возвращенный методом FileInfo.Create(), обеспечивает полный доступ чтения/записи всем пользователям.

Метод FileInfo.Open()

Метод FileInfо.Open() можно использовать для того, чтобы открывать существующие файлы и создавать новые с более точными характеристиками, чем при использовании FileInfo.Create(). В результате вызова Open() возвращается объект FileStream. Рассмотрите следующий пример.

static void Main(string[] args) {

 …

 // Создание нового файла с помощью FileInfo.Open().

 FileInfo f2 = new FileInfo(@"C:\Test2.dat");

 FileStream fs2 = f2.Open(FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.None);

 // Использование объекта FileStream.…

 // Закрытие файлового потока.

 fs2.Close();

}

Эта версия перегруженного метода Open() требует указания трех параметров. Первый параметр задает общий вид запроса ввода-вывода (создание нового файла, открытие существующего файла, добавление данных в файл и т.п.) с помощью перечня FileMode.

public enum FileMode {

 // Дает операционной системе указание создать новый файл.

 // Если файл уже существует, генерируется System.IO.IOException.

 CreateNew,

 // Дает операционной системе указание создать новый файл,

 // Если файл уже существует, он будет переписан.

 Create,

 Open,

 // Дает операционной системе указание открыть файл,

 // если он существует, иначе следует создать новый файл.

 OpenOrCreate,

 Truncate,

 Append

}

Второй параметр, значение из перечня FileAccess, используется для определения характеристик чтения/записи в соответствующем потоке.

public enum FileAccess {

 Read,

 Write,

 ReadWrite

}

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

public enum FileShare {

 None,

 Read,

 Write,

 ReadWrite

}

Методы FileInfo.OpenRead() и FileInfo.OpenWrite()

Хотя метод FileInfo.Open() и обладает очень гибкими возможностями получения дескриптора файла, класс FileInfo также предлагает члены с именами OpenRead() и OpenWrite(). Как вы можете догадаться, эти методы возвращают должным образом сконфигурированный только для чтения или только для записи тип FileStream, без необходимости указания соответствующих значений перечней.

Подобно FileInfo.Create() и FileInfo.Open(), методы OpenRead() и OpenWrite() возвращают объект FileStream.

static void Main(string[] args) {

 …

 // Получение объекта FileStream с доступом только для чтения.

 FileInfo f3 = new FileInfo(@"C:\Test3.dat");

 FileStream readOnlyStream = f3.OpenRead();

 // Использование объекта FileStream…

 readOnlyStream.Close();

 // Получение объекта FileStream с доступом только для записи.

 FileInfо f4 = new FileInfo(@"C:\Test4.dat");

 FileStream writeOnlyStream = f4.OpenWrite();

 // Использование объекта FileStream…

 writeOnlyStream.Close();

}

Метод FileInfo.OpenText()

Другим членом типа FileInfo, связанным с открытием файлов, является OpenText(). В отличие от Create(), Open(), OpenRead() и OpenWrite(), метод OpenText() возвращает экземпляр типа StreamReader, а не типа FileStream.

static void Main(string[] args) {

 …

 // Получение объекта StreamReader.

 FileInfo f5 = new FileInfо(@"C:\boot.ini");

 StreamReader sreader = f5.OpenText();

 // Использование объекта StreamReader.…

 sreader.Close();

}

Чуть позже вы увидите, что тип StreamReader обеспечивает возможность чтения символьных данных из соответствующего файла.

Методы FileInfo.CreateText() и FileInfo.AppendText()

И последними интересующими нас на этот момент методами будут CreateText() и AppendText(), которые возвращают ссылку на StreamWriter, как показано ниже.

static void Main(string[] args) {

 …

 FileInfo f6 = new FileInfo(@"C:\Test5.txt");

 StreamWriter swriter = f6.CreateText();

 // Использование объекта StreamWriter….

 swriter.Close();

 FileInfo f7 = new FileInfo(@"C:\FinalTest.txt");

 StreamWriter swriterAppend = f7.AppendText();

 // Использование объекта StreamWriter…

 swriterAppend.Close();

}

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

Тип File предлагает функциональные возможности, почти идентичные возможностям типа FileInfo, но с помощью ряда статических членов. Подобно FileInfo, тип File предлагает методы AppendText(), Create(), CreateText(), Open(), OpenRead(), OpenWrite() и OpenText(). Во многих случаях типы File и

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

static void Main(string[] args) {

 // Получение объекта FileStream с помощью File.Create() .

 FileStream fs = File.Create(@"C:\Test.dat");

 fs.Close();

 // Получение объекта FileStream с помощью File.Open().

 FileStream fs2 = File.Open(@"C:\Test2.dat", FileMode.OpenOrCreate, FileAccess.ReadWrite, FileShare.None);

 fs2.Close();

 // Получение объекта FileStream с доступом только для чтения.

 FileStream readOnlyStream = File.OpenRead(@"Test3.dat");

 readOnlyStream.Close();

 // Получение объекта FileStream с доступом только для записи.

FileStream writeOnlyStream = File.OpenWrite(@"Test4.dat");

 writeOnlyStream.Close();

 // Получение объекта StreamReader.

 StreamReader sreader = Filе.OpenText(@"C:\boot.ini");

 sreader.Close();

 // Получение нескольких объектов StreamWriter.

 StreamWriter swriter = File.CreateText(@"C:\Test3.txt");

 swriter.Close();

 StreamWriter swriterAppend = File.AppendText(@"C:\FinalTest.txt");

 swriterAppend.Close();

}

Новые члены File в .NET 2.0

В отличие от FileInfo, тип File поддерживает (в .NET 2.0) несколько своих собственных уникальных членов, описания которых приводятся в табл. 16.5. С помощью этих членов можно существенно упростить процессы чтения и записи текстовых данных.

Таблица 16.5. Методы типа File

При использовании этих новых методов типа File для чтения и записи пакетов данных потребуется всего несколько строк программного кода. Более того, каждый из указанных новых членов автоматически закрывает соответствующий дескриптор файла, например:

class Program {

 static void Main(string[] args) {

  string[] myTasks = { "Прочистить сток в ванной", "Позвонить Саше и Сереже", "Позвонить родителям", "Поиграть с ХВох" };

 // Записать все данные в файл на диске C.

 File.WriteAllLines(@"C:\tasks.txt", myTasks);

 // Прочитать все снова и напечатать.

  foreach (string task in File.ReadAllLines(@"C:\tasks.txt")) {

   Console.WriteLine("Нужно сделать: {0}", task);

 }

 }

}

Очевидно, когда вы хотите быстро получить дескриптор файла, тип File избавит вас от необходимости ввода нескольких лишних строк. Однако преимущество предварительного создания объекта FileInfo заключается в том, что тогда вы получаете возможность исследовать соответствующий файл с помощью членов абстрактного базового класса FileSystemInfо.

static void Main(string[] args) {

 // Вывод информации о файле boot.ini

 // с последующим открытием доступа только для чтения.

 FileInfo bootFile = new FileInfо(@"C:\boot.ini");

 Console.WriteLine(bootFile.CreationTime);

 Console.WriteLine(bootFile.LastAccessTime);

 FileStream readOnlyStream = bootFile.OpenRead();

 readOnlyStream.Close();

}

К этому моменту вы уже видели множество способов получения объектов FileStream, StreamReader и StreamWriter, но вам придется еще читать и записывать данные файлов, связанных с этими типами. Чтобы понять, как это делается, нужно ознакомиться с понятием потока. В "мире" ввода-вывода поток представляет порцию данных. Потоки обеспечивают общую возможность взаимодействия с последовательностями байтов, независимо от того, на устройстве какого вида (в файле, сетевом соединении, принтере и т.п.) они хранятся или отображаются.

Абстрактный класс System.IO.Stream определяет ряд членов, обеспечивающих поддержку синхронного и асинхронного взаимодействия с носителем данных (скажем, с файлом или областью памяти). На рис. 16.6 показано несколько потомков типа Stream.

Рис. 16.6. Типы, производные от Stream

Замечание. Следует знать, что понятие потока применимо не только к файлам или области памяти. Без сомнения, библиотеки .NET обеспечивают потоковый доступ к сетям и другим связанным с потоками абстракциям.

Напомним, что потомки stream представляют данные в виде "сырого" потока байтов, поэтому работа с потоками может быть весьма непонятной. Некоторые относящиеся к Stream типы поддерживают поиск – этот термин, по сути, означает процесс получения он изменения текущей позиции в потоке. Чтобы понять функциональные возможности, предлагаемые классом Stream, рассмотрите его базовые члены, описанные в табл. 16.6.

Таблица 16.6. Абстрактные члены Stream

Работа с FileStream

Класс FileStream обеспечивает реализацию абстрактных членов Stream в виде, подходящем для файловых потоков. Это довольно примитивный поток – он может читать или записывать только один байт или массив байтов. На самом деле необходимость непосредственного взаимодействия с членами типа FileStream возникает очень редко. Вы чаще будете использовать различные упаковщики потоков, которые упрощают работу с текстовыми данными или типами .NET. Однако для примера давайте поэкспериментируем со средствами синхронного чтения/записи типа FileStream.

Предположим, что мы создали новое консольное приложение FileStreamApp. Нашей целью является запись простого текстового сообщения в новый файл с именем myMessage.dat. Но поскольку FileStream может воздействовать только на отдельные байты, требуется перевести тип System.String в соответствующий массив байтов. К счастью, в пространстве имен System.Text определяется тип Encoding, предлагающий члены, которые выполняют кодирование и декодирование строк и массивов байтов (для подробного описания типа Encoding обратитесь к документации .NET Framework 2.0 SDK).

После выполнения кодирования массив байтов переводится в файл с помощью метода FileStream.Write(). Чтобы прочитать байты обратно в память, необходимо переустановить внутренний указатель позиции потока (с помощью свойства Position) и вызвать метод ReadByte(). Наконец, массив байтов и декодированная строка выводятся на консоль. Вот полный текст соответствующего метода Main().

// Не забудьте 'использовать' System.Text.

static void Main(string[] args) {

 Console.WriteLine("***** Забавы с FileStreams *****\n");

 // Получение объекта FileStream.

 FileStream fStream = File.Open(@"C:\myMessage.dat", FileMode.Create);

 // Кодирование строки в виде массива байтов.

 string msg = "Привет!";

 byte[] msgAsByteArray = Encoding.Default.GetBytes(msg);

 // Запись byte[] в файл.

 fStream.Write(msgAsByteArray, 0, msgAsByteArray.Length);

 // Переустановка внутреннего указателя позиции потока.

 fStream.Position = 0;

 // Чтение типов из файла и вывод на консоль….

 Console.Write("Ваше сообщение в виде массива байтов: ");

 byte[] bytesFromFile = new byte[msgAsByteArray.Length];

 for (int i = 0; i ‹ msgAsByteArray.Length; i++) {

  bytesFromFile[i] = (byte)fStream.ReadByte();

  Console.Write(bytesFromFile[i]);

 }

 // Вывод декодированного сообщения.

 Console.Write("\nДекодированное сообщение: ");

 Console.WriteLine(Encoding.Default.GetString(bytesFromFile));

 // Завершение потока.

 fStream.Close();

}

Хотя в этом примере файл данными не заполняется, уже здесь становится очевидным главный недостаток работы с типом FileStream: приходится воздействовать непосредственно на отдельные байты. Другие типы, являющиеся производными от Strеаm, работают аналогично. Например, чтобы записать последовательность байтов в заданную область памяти, можно использовать MemoryStream. Точно так же, чтобы передать массив байтов по сети, вы можете использовать тип NetworkStream.

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

Исходный код. Проект FileStreamApp размещен в подкаталоге, соответствующем главе 16.

Классы StreamWriter и StreamReader оказываются полезны тогда, когда приходится читать или записывать символьные данные (например, строки). Оба эти типа по умолчанию работают с символами Unicode, однако вы можете изменить эти установки, предоставив ссылку на правильно сконфигурированный объект System.Text.Encoding. Чтобы упростить рассмотрение, предположим, что предлагаемое по умолчавию кодирование в символы Unicode как раз и является подходящим.

Тип StreamReader получается из абстрактного типа TextReader. To же можно сказать и о родственном типе StringReader (он будет обсуждаться в этой главе позже). Базовый класс TextReader обеспечивает каждому из этих "последователей" очень небольшой набор функциональных возможностей, среди которых, в частности, возможность чтения символов из потока и их добавление в поток.

Тип StreamWriter (как и StringWriter, который также будет рассматриваться позже) получается из абстрактного базового класса TextWriter. Этот класс определяет члены, позволяющие производным типам записывать текстовые данные в имеющийся символьный поток. Взаимосвязь между этими новыми типами ввода-вывода показана на рис. 16.7.

Чтобы помочь вам понять возможности записи классов StreamWriter и StringWriter, в табл. 16.7 предлагаются описания основных членов абстрактного базового класса TextWriter.

Рис. 16.7. Читатели и писатели

Таблица 16.7. Основные члены TextWriter

Замечание. Последние два из указанных в таблице членов класса TextWriter, вероятно, покажутся вам знакомыми. Если вы помните, у типа System.Console есть члены Write() и WriteLine(), записывающие текстовые данные в устройство стандартного вывода. На самом деле свойство Console.In является упаковкой для TextWriter, а свойство Console.Out – для TextReader.

Производный класс StreamWriter обеспечивает подходящую реализацию методов Write(), Close() и Flush() и определяет дополнительное свойство AutoFlush. Это свойство, когда его значение равно true (истина), заставляет StreamWriter при выполнении операции записи записывать все данные. Можно добиться лучшей производительности, если установить для AutoFlush значение false (ложь), поскольку иначе при каждой записи StreamWriter будет вызываться Close().

Запись в текстовый файл

Рассмотрим пример работал с типом StreamWriter. Следующий класс создает новый файл reminders.txt с помощью метода File.CreateText(). С помощью полученного объекта StreamWriter в новый файл добавляются определенные текстовые данные, как показано ниже.

static void Main(string[] args) {

 Console.WriteLine("*** Забавы с StreamWriter/StreamReader ***\n");

 // Получение StreamWriter и запись строковых данных.

 StreamWriter writer = File.CreateText("reminders.txt");

 writer.WriteLine("Нe забыть о дне рождения мамы…");

 writer.WriteLine("Не забыть о дне рождения папы…");

 writer.WriteLine("Не забыть о следующих числах:");

 for(int i = 0; i ‹ 10; i++) writer.Write(i + " ");

 // вставка новой строки.

 writer.Write(writer.NewLine);

 // Закрытие автоматически влечет запись всех оставшихся данных!

 writer.Close();

 Console.WriteLine("Создан файл и записаны некоторые идеи…");

}

Выполнив эту программу, вы можете проверить содержимое нового файла (рис. 16.8).

Рис. 16.8. Содержимое вашего файла * .txt

Чтение из текстового файла

Теперь выясним, как программными средствами читать данные из файла, используя соответствующий тип StreamReader. Вы должны помнить, что этот класс получается из TextReader, функциональные возможности которого описаны в табл. 16.8.

Таблица 16.8. Основные члены TextReader

Если теперь расширить имеющийся класс MyStreamWriter.Reader, чтобы использовать в нем StreamReader, вы сможете прочитать текстовые данные из файла reminders.txt, как показано ниже.

static void Main(string[] args) {

 Console.WriteLine("*** Забавы с StreamWriter/StreamReader ***\n");

 …

 // Теперь чтение данных из файла.

 Console.WriteLine("Вот ваши идеи:\n");

 StreamReader sr = File.OpenText("reminders.txt");

 string input = null;

 while ((input = sr.ReadLine()) != null) {

  Console.WriteLine(input);

 }

}

Выполнив программу, вы увидите символьные данные из reminders.txt, выведенные на консоль.

Непосредственное создание типов StreamWriter/StreamReader

Одной из смущающих особенностей работы с типами из System.IO является то, что часто одних и тех же результатов можно достичь в рамках множества подходов. Например, вы видели, что можно получить StreamWriter из File или из FileInfo, используя метод CreateText(). На самом деле есть еще одна возможность получения StreamWriters и StreamReaders – это непосредственное их создание. Например, наше приложение можно было бы переписать в следующем виде.

static void Main(string[] args) {

 Console.WriteLine("*** Забавы с StreamWriter/StreamReader ***\n");

 // Get a StreamWriter and write string data.

 StreamWriter writer = new StreamWriter("reminders.txt");

 …

 // Now read data from file.

 StreamReader sr = new StreamReader("reminders.txt");

 …

}

Видеть так много идентичных, на первый взгляд, подходов к реализации ввода-вывода, может быть, немного странно, но имейте в виду, что конечным результатом здесь оказывается гибкость. Так или иначе, вы смогли увидеть, как можно извлекать символьные данные из файлов и помещать их в файлы, используя типы StreamWriter и StreamReader, и теперь мы с вами можем рассмотреть роль классов StringWriter и StringReader.

Исходный код. Проект StreamWriterReaderApp размещен в подкаталоге, соответствующем главе 16.

Термин сериализация означает процесс переноса состояния объекта в поток, Соответствующая сохраненная последовательность данных содержит всю информацию, необходимую для реконструкции объекта, если в дальнейшем возникает необходимость в его использовании. С помощью такой технологии очень просто сохранять огромные объемы данных (в самых разных форматах). Во многих случаях сохранение данных приложения с помощью сервиса сериализации оказывается намного менее неуклюжим, чем прямое использование средств чтения/записи, предлагаемых в рамках пространства имен System.IO.

Предположим, например, что вы создали приложение с графическим интерфейсом и хотите обеспечить конечным пользователям возможность сохранить информацию об их предпочтениях. Для этого вы можете определить класс (например, с именем UserPrefs), инкапсулирующий, скажем, 20 полей данных. Если использовать тип System.IO.BinaryWriter, вам придется вручную сохранять каждое поле объекта UserPrefs. А когда вы захотите загрузить данные из соответствующего файла обратно в память, вам придется использовать System.IO.BinaryReader и (снова вручную) прочитать каждое значение, чтобы сконфигурировать новый объект UserPrefs.

Это, конечно, выполнимо, но вы можете сэкономить себе немало времени, просто указав для класса UserPrefs атрибут [Serializable]. В этом случае для сохранения полного состояния объекта достаточно будет нескольких строк программного кода.

static void Main(string[] args) {

 // Предполагаем, что для UserPrefs

 // указано [Serializable].

 UserPrefs userData = new UserPrefs();

 userData.WindowColor = "Yellow";

 userData.FontSize = "50";

 userData.IsPowerUser = false;

 // Теперь сохраним объект в файле user.dat.

 BinaryFormatter binFormat = new BinaryFormatter();

 Stream fStream = new FileStream("user.dat", FileMode.Create, FileAccess.Write, FileShare.None);

 binFormat.Serialize(fStream, userData); fStream.Close();

 Console.ReadLine();

}

Сохранять объекты с помощью средств сериализации .NET очень просто, но процессы, происходящие при этом в фоновом режиме, оказываются весьма сложными. Например, когда объект сохраняется в потоке, все соответствующие данные (базовые классы, вложенные объекты и т.п.) автоматически сохраняются тоже. Таким образом, при попытке выполнить сериализацию производного класса в этом процессе будет задействована вся цепочка наследования.

Как вы сможете убедиться позже, множество взаимосвязанных объектов можно представить в виде объектного графа. Сервис сериализации .NET позволяет сохранить и объектный граф, причем в самых разных форматах. В предыдущем примере программного кода использовался тип BinaryFormatter, поэтому состояние объекта UserPrefs сохранялось в компактном двоичном формате. Если использовать другие типы, то объектный граф можно сохранить в формате SOAP (Simple Object Access Protocol – простой протокол доступа к объектам) или в формате XML. Эти форматы могут быть полезны тогда, когда необходимо гарантировать, что ваши сохраненные объекты легко перенесут "путешествие" через операционные системы, языки и архитектуры.

Наконец, следует понимать, что объектный граф можно сохранить в любом производном от System.IO.Stream типе. В предыдущем примере объект UserPrefs сохранялся в локальном файле с помощью типа FileStream. Но если бы требовалось сохранить объект в памяти, следовало бы использовать тип MemoryStream. Это необходимо для того, чтобы последовательность данных корректно представляла состояния объектов соответствующего графа.

Роль объектных графов

Как уже упоминалось, при сериализации объекта среда CLR учитывает состояния всех связанных объектов. Множество связанных объектов представляется объектным графом. Объектные графы обеспечивают простой способ учета взаимных связей в множестве объектов, и не обязательно, чтобы эти связи в точности проецировались в классические связи объектно-ориентированного программирования (такие как отношения старшинства, и подчиненности), хотя они моделируют эту парадигму достаточно хорошо.

Каждому объекту в объектном графе назначается уникальное числовое значение. Следует иметь в виду, что эти числовые значения, приписываемые членам в объектном графе, произвольны и не имеют никакого смысла вне графа. После назначения всем объектам числового значения объектный граф может начать запись множества зависимостей каждого объекта.

Для примера предположим, что вы создали множество классов, моделирующих типы автомобилей (а что же еще?). Вы имеете базовый класс, названный Car (автомобиль), который "имеет" Radio (радио). Другой класс, JamesBondCar (автомобиль Джеймса Бонда), расширяет базовый тип Car. На рис. 17.1 показан возможный объектный граф, моделирующий указанные взаимосвязи.

Рис. 17.1 Простой объектный граф

При чтении объектных графов дли соединяющих стрелок вы можете использовать выражения "зависит от" и "ссылается на". Поэтому на рис. 17.1 вы можете видеть, что класс Car ссылается на класс Radio (в силу отношения локализации, "has-a"), а класс JamesBondCar ссылается на Car (в силу отношения подчиненности, "is-а") и на Radio (в силу того, что соответствующий защищенный член-переменная данным классом наследуется).

Конечно, для представления графа связанных объектов среда CLR картины в памяти не рисует. Вместо этого взаимосвязи, указанные в диаграмме, представляются математической формулой, которая выглядит примерно так.

[Car 3, ref 2], [Radio 2], [JamesBondCar 1, ref 3, ref 2]

Проанализировав эту формулу, вы снова увидите, что объект 3 (Car) имеет зависимость в отношения объекта 2 (Radio). Объект 2 (Radio) является "индивидуалистом", которому никто не требуется. Наконец, объект 1 (JamesBondCar) имеет зависимость в отношении как объекта 3, так и объекта 2. В любом случае, когда выполняется сериализация или реконструкция экземпляра JamesBondCar, объектный граф дает гарантию того, что типы Radio и Car тоже будут участвовать в процессе.

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

Чтобы сделать объект доступным сервису сериализации .NET, достаточно пометить каждый связанный класс атрибутом [Serializable]. И это все (правда!). Если вы решите, что некоторые члены данного класса не должны (или, возможно, не могут) участвовать в процессе сериализации, обозначьте соответствующие поля атрибутом [NonSerialized]. Это может быть полезно тогда, когда в классе, предназначенном для сериализации, есть члены-переменные, которые запоминать не нужно (например, фиксированные или случайные значения, динамические данные и т.п.), и вы хотите уменьшить размеры сохраняемого графа.

Для начала вот вам класс Radio, обозначенный атрибутом [Serializable], за исключением одной переменной (radioID), которая помечена атрибутом [NonSerialized], и поэтому не будет сохраняться в указанном потоке данных.

[Serializable] 

public class Radio {

 public bool hasTweeters;

 public bool hasSubWoofers;

 public double[] stationPresets;

 [NonSerialized]

 public string radioID = "XF-552RR6";

}

Класс JamesBondCar и базовый класс Car, также обозначенные атрибутом [Serializable], определяют следующие поля данных.

[Serializable] 

public class Car {

 public Radio theRadio = new Radio();

 public bool isHatchBack;

}

[Serializable]

public class JamesBondCar: Car {

 public bool canFly;

 public bool canSubmerge;

}

Следует знать о том, что атрибут [Serializable] не наследуется. Таким образом, если вы получаете класс из типа, обозначенного атрибутом [Serializable], дочерний класс тоже следует обозначить атрибутом [Serializable], иначе он при сериализации сохраняться не будет. На самом деле все объекты в объектном графе должны обозначаться атрибутом [Serializable]. При попытке с помощью BinaryFormatter или SoapFormatter выполнить сериализацию объекта. не подлежащего сериализации, в среде выполнения генерируется исключение SerializationException.

Открытые поля, приватные поля и открытые свойства

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

"Отодвинув" принципы объектно-ориентированного программирования в сторону, вы можете спросить, какие именно определения полей данных ожидают "видеть" различные средства форматирования, при отправке этих данных в поток. Ответ здесь зависит от многого. Если вы сохраняете объект с помощью BinaryFormatter, то определения не имеют абсолютно никакого значений. Этот тип предназначен дан сохранения всех предназначенных для сериализации полей типа, независимо от того, являются ли они общими полями, приватными полями или приватными полями, доступными через свойства типа. Однако ситуация оказывается совершенно иной, если вы используете тип XmlSerializer или тип SoapFormatter. Эти типы выполняют сериализацию только открытых полей данных и приватных данных, доступных через открытые свойства.

Напомним, однако, что если имеются поля данных, которые вы не хотите сохранять в объектном графе, вы можете селективно использовать для них атрибут [NonSerialized], как это сделано со строковым полем типа Radio.

После конфигурации типов для участия в схеме сериализации .NET следующим шагом является выбор формата, который должен использоваться при сохранении объектного графа. В .NET 2.0 вы имеете на выбор три варианта.

• BinaryFormatter

• SoapFormatter

• XmlSerializer

Тип BinaryFormatter выполняет сериализацию объектного графа в поток, используя компактный двоичный формат. Этот тип определен в рамках пространства имен System.Runtime.Serialization.Formatters.Binary, являющегося частью mscorlib.dll. Таким образом, для сериализации объектов с использованием двоичного формата нужно только указать (в C#) следующую директиву using.

// Получение доступа к BinaryFormatter из mscorlib.dll.

using System.Runtime.Serialization.Formatter.Binary;

Тип SoapFormatter представляет граф в виде сообщения SOAP. Этот тип определен в пространстве имен System.Runtime.Serialization.Formatters.Soap, которое содержится в отдельном компоновочном блоке. Поэтому, чтобы представить объектный граф в формате сообщения SOAP, вы должны добавить ссылку на System.Runtime.Serialization.Formatters.Soap.dll и указать (в C#) следующую директиву using.

// Должна быть указана ссылка

// на System.Runtime.Serialization.Formatters.Soap.dll!

using System.Runtime.Serialization.Formatters.Soap;

Наконец, чтобы сохранить объектный граф в формате документа XML, нужно указать ссылку на пространство имен System.Xml.Serialization, которое также определено в отдельном компоновочном блоке – System.Xml.dll. Поскольку все шаблоны проектов в Visual Studio 2005 автоматически ссылаются на System.Xml.dll, вам нужно просто использовать следующее пространство имен.

// Определено в System.Xml.dll.

using System.Xml.Serialization;

Интерфейсы IFormatter и IRemotingFormatter

Независимо от того, какой формат вы выберете для использования, все они получаются прямо из System.Object и поэтому не могут иметь общего набора членов, наследуемого от какого-либо базового класса сериализации. Однако типы BinaryFormatter и SoapFormatter имеют общее множество членов по причине реализации интерфейсов IFormatter и IRemotingFormatter (тип XmlSerializer не реализует ни одного из них).

Интерфейс System.Runtime.Serialization.IFormatter определяет базовые методы Serialize() и Deserialize(), выполняющие основную работу по перемещению объектных графов в поток и из него. Кроме этих членов, IFormatter определяет несколько свойств, которые используются реализующим типом в фоновом режиме.

public interface IFormatter {

 SerializationBinder Binder { get; set; }

 StreamingContext Context { get; set; }

 ISurrogateSelector SurrogateSelector { get; set; }

 object Deserialize(System.IO.Stream serializationStream);

 void Serialize(System.IO.Stream serializationStream, object graph);

}

Интерфейс System.Runtime.Remoting.Messaging.IRemotingFormatter (который используется в .NET на уровне удаленного взаимодействия) предлагает перегруженные члены Serialize() и Deserialize(), более подходящие для использования в распределенных операциях. Заметьте, что IRemotingFormatter получается из более общего интерфейса IFormatter.

public interface IRemotingFormatter : IFormatter {

 object Deserialize(Stream serializationStream, HeaderHandler handler);

 void Serialize(Stream serializationStream, object graph, Header[] headers);

}

Хотя в большинстве операций сериализации вам, возможно, и не придется взаимодействовать с этими интерфейсами непосредственно, не забывайте о том, что интерфейсный полиморфизм дозволяет использовать экземпляр BinaryFormatter или SoapFormatter по ссылке на IFormatter. Таким образом, чтобы построить метод, выполняющий сериализацию объектного графа с помощью любого из этих классов, вы можете использовать следующий программный код.

static void SerializeObjectGraph(IFormatter itfFormat, Stream destStream, object graph) {

 itfFormat.Serialize(destStream, graph);

}

Выбор формата и точность типов

Очевидно, сутью различий указанных трех форматов является то, как именно объектный граф переводится в поток (в двоичном формате, формате SOAP или "чистом" XML). Но следует знать и о нескольких более "утонченных" различиях, особенно в отношении того, насколько различные форматы гарантируют точность типа. При использовании типа BinarуFormatter будут сохраняться не только поля данных объектов из объектного графа, но и абсолютное имя каждого типа, а также полное имя определяющего тип компоновочного блока. Эти дополнительные элементы данных делают BinaryFormatter идеальный выбором, когда вы хотите передать объекты по значению (например, как полную копию) за границы машины (см. главу 18). Как уже отмечалось, чтобы достичь такого уровня точности, BinaryFormatter учитывает все поля данных типа (как открытые, так и приватные).

Но SoapFormatter и XmlSerializer, с другой стороны, не пытаются сохранить тип абсолютно точно, поэтому они не записывают абсолютные имена типов и компоновочных блоков, а сохраняют только открытые поля данных и открытые свойства. На первый взгляд, это кажется ограничением, но реальная причина этого скрывается в открытой природе представления данных XML. Если вы хотите сохранить объектные графы так, чтобы они могли использоваться в любой операционной системе (Windows XP, ОС Маc X, различные вариации *nix), в рамках любого каркаса приложений (.NET. J2EE, COM и т.д.) и любом языке программирования, нет необходимости поддерживать абсолютную точность, поскольку у вас нет гарантии, что все возможные получатели смогут понять типы данных, специфичные для .NET. В этом случае идеальным выбором являются SoapFormatter и XmlSerializer, гарантирующие наиболее широкую доступность сохраненного объектного графа.

Чтобы показать, как сохранить экземпляр JamesBondCar в физическом файле, давайте используем тип BinaryFormatter. Подчеркнем снова, что двумя ключевыми методами типа BinaryFormatter являются Serialize() и Deserialize().

• Serialize(). Сохраняет объектный граф в указанном потоке в виде последовательности байтов.

• Deserialize(). Преобразует сохраненную последовательность байтов в объектный граф.

Предположим, что мы создали экземпляр JamesBondCar, изменили в нем некоторые данные и хотим сохранить этот "шпиономобиль" в файле *.dat. Первой нашей задачей является создание самого файла *.dat. Это можно сделать с помощью создания экземпляра типа System.IO.FileStream (см. главу 16). Создайте экземпляр BinaryFormatter и передайте ему FileStream и объектный граф для сохранения.

using System.Runtime.Serialization.Formatters.Binary; using System.IO;

 …

 static void Main (string[] args) {

 Console.WriteLine("*** Забавы с сериализацией объектов ***\n");

 // Создание JamesBondCar и установка данных состояния.

 JamesBondCar jbc = new JamesBondCar();

 jbc.canFly = true;

 jbc.canSubmerge = false;

 jbc.theRadio.statio.nPresets = new double[]{89.3, 105.1, 97.1};

 jbc.theRadio.hasTweeters = true;

 // Сохранение объекта в файл CarData.dat в двоичном формате.

 BinaryFormatter binFormat = new BinaryFormatter();

 Stream fStream = new FileStream("CarData.dat", FileMode.Create, FileAccess.Write, FileShare.None);

 binFormat.Serialize(fStream, jbc);

 fStream.Close();

 Console.ReadLine();

}

Как видите, метод BinaryFormatter.Serialize() отвечает за компоновку объектного графа и передачу соответствующей последовательности байтов некоторому типу, производному от Stream. В данном случае таким потоком является физический файл. Однако можно выполнять сериализацию объектных типов в любой производный от Stream тип, например в память, поскольку MemoryStream тоже является потомком типа Stream.

Реконструкция объектов с помощью BinaryFormatter

Теперь предположим, что вы хотите прочитать сохранённые данные JamesBondCar из двоичного файла назад в объектную переменную. Программно открыв CarData.dat (с помощью метода OpenRead()), вызовите метод Deserialize() объекта BinaryFormatter. Метод Deserialize() возвращает общий тип System.Object, поэтому вам придется выполнить явное преобразование, как показано ниже.

static void Main(string[] args) {

 …

 // Чтение JamesBondCar из двоичного файла.

 fStream = File.OpenRead("CarData.dat");

 JamesBondCar carFromDisk = (JamesBondCar)binFormat.Deserialize(fStream);

 Console.WriteLine("Может ли машина летать?: {0}", carFromDisk.canFly);

 fStream.Close();

 Console.ReadLine();

}

Обратите внимание на то, что при вызове Deserialize() методу передается производный от Stream тип, указывающий место хранения объектного графа (в данном случае это файловый поток). Так что проще уже некуда. По сути, сначала нужно обозначить атрибутом [Serializable] все классы, предназначенные для сохранения в потоке. После этого нужно использовать тип BinaryFormatter, чтобы передать объектный граф в двоичный поток и извлечь его оттуда. Вы можете увидеть двоичный образ, представляющий экземпляр JamesBondCar (рис. 17.2).

Рис. 17.2. Сериализация JamesBondCar с помощью BinaryFormatter

Вдобавок к SOAP и двоичному формату, компоновочный блок System.Xml.dll предлагает третий формат, обеспечиваемый типом System.Xml.Serialization. XmlSerializer который может использоваться для сохранения состояния данного объекта в виде "чистого" XML в противоположность данным XML, упакованным в сообщении SOAP. Работа с этим типом немного отличается от работы с типами SoapFormatter и BinaryFormatter. Рассмотрим следующий программный код.

using Sуstem.Xml.Serialization;

…

static void Main(string[] args) {

 …

 // Сохранение объекта в файл CarData.xml в формате XML.

 XmlSerializer xmlFormat = new XmlSerializer(typeof(JamesBondCar), new Type[] { typeof(Radio), typeof(Car) });

 fStream = new FileStream("CarData.xml", FileMode.Create, FileAccess.Write, FileShare.None);

 xmlFormat.Serialize(fStream, jbc);

 fStream.Close();

 …

}

Здесь главным отличием является то, что тип XmlSerializer требует указания информации о типе соответствующего элемента объектного графа. Обратите внимание на то, что первый аргумент конструктора XmlSerializer определяет корневой элемент XML-файла, а второй аргумент является массивом типов System.Type, содержащих метаданные подчиненных элементов. Если заглянуть в сгенерированный файл CarData.xml, вы увидите следующий XML-код (здесь он приводится в сокращенном виде).

‹?xml version="1.0" encoding="utf-8"?›

 ‹JamesBondCar xmlns:xsi="…"›

 ‹theRadio›

  ‹hasTweeters›true‹/hasTweeters›

  ‹hasSubWoofers›false‹/hasSubwoofers›

  ‹stationPresets›

   ‹double›89.3‹/double›

   ‹double›105.1‹/double›

   ‹double›97.1‹/double›

   ‹/stationPresets›

  ‹/theRadio›

  ‹isHatchBack›false‹/isHatchBack›

 ‹canFly›true‹/canFly›

 ‹canSubmerge›false‹/canSubmerge›

 ‹/JamesBondCar›

Замечание. Для XmlSerializer требуется, чтобы все типы в объектном графе, предназначенные для сериализации, поддерживали конструктор, заданный по умолчанию (так что не забудьте добавить его, если вы определили пользовательские конструкторы). Если это условие не будет выполнено, в среде выполнения будет сгенерировано исключение InvalidOperationException.

Контроль генерируемых XML-данных

Если у вас есть опыт использования XML-технологий, вы должны хорошо знать о том, что в документе XML очень важно гарантировать соответствие элементов набору правил, обеспечивающих "допустимость" данных. Следует понимать, что "допустимость" XML-документа не связана напрямую с синтаксической правильностью его XML-элементов (например, с требованием о том, что все открываемые элементы должны иметь закрывающие их дескрипторы). Скорее, допустимость документов связана с правилами форматирования (например, поле X должно быть атрибутом и не вложенным элементом), которые обычно задаются XML-схемой или DTD-файлом (файл определения типа документа),

По умолчанию все поля данных типа [Serializable] форматируются, как элементы, а не как XML-атрибуты. Для контроля того, как XmlSerializer компонует генерируемый XML-документ, следует указать для типов [Serializable] дополнительные атрибуты из пространства имен System.Xml.Serialization. В табл. 17.1 представлены некоторые из атрибутов, влияющих на кодирование XML-данных, передаваемых в поток.

Таблица 17.1. Атрибуты пространства имен System.Xml.Serialization, связанные с сериализацией объектов

Для примера давайте сначала выясним, как поля данных JamesBondCar сохраняются в XML-документе в настоящий момент.

‹?xml version="1.0" encodings="utf-8"?›

‹JamesBondCar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd=http://www.w3.org/2001/XMLSchema›

 …

 ‹canFly›true‹/canFly›

 ‹canSubmerge›false‹/canSubmerge›

‹/JamesBondCar›

Если вы хотите указать пользовательское пространство имен XML, соответствующее JamesBondCar, и кодировать значения canFly и canSubmerge в виде XML-атрибутов, это можно сделать с помощью изменения определения JamesBondCar в C# следующим образом.

[Serializablе, XmlRoot(Namespace = "http://www.intertechtraining.com")]

public class JamesBondCar: Car {

 …

 [XmlAttribute]

 public bool canFly;

 [XmlAttribute]

 public bool canSubmerge;

}

Это должно дать в результате следующий XML-документ (обратите внимание на открывающий элемент ‹JamesBondCar›).

‹?xml version="1.0" encodin="utf-8"?›

‹JamesBondCar xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" canFly="true" canSubmerge="false"

xmlns="http://www.intertechtraining.com"›

 …

‹/JamesBondCar›"

Конечно, есть множество других атрибутов, которые вы можете использовать для управления процессом генерирования XML-документа с помощью XmlSerializer. Чтобы ознакомиться со всеми опциями, выполните поиск информации о пространстве имен System.Xml.Serialization в документации .NET Framework 2.0 SDK

В большинстве случаев типовая схема сериализации, предлагаемая платформой .NET, будет именно тем, что требуется. Тогда нужно просто применить атрибут [Serializable] и передать объектный граф выбранному средству форматирования. Но в некоторых случаях может потребоваться корректировка того, как обрабатывается объектный граф в процессе сериализации. Например, в соответствии с внутренними правилами вашей компании все поля данных должны сохраняться в формате верхнего регистра или, возможно, вы хотите добавить в поток дополнительные элементы данных, которые не проецируются непосредственно в поля сохраняемого объекта (это могут быть штампы времени, уникальные имена или что-то иное).

Для непосредственного участия в управлении процессом сериализации объектов пространство имен System.Runtime.Serialization предлагает специальные типы. В табл. 17.2 описаны те из них, о которых вам следует знать.

Таблица 17.2. Основные типы пространства имен System.Runtime.Serialization

Более глубокий взгляд на сериализацию объектов

Перед тем как рассмотреть различные способы настройки параметров процесса сериализации, было бы полезно выяснить, что при этом происходит "за кулисами". Когда тип BinaryFormatter выполняет сериализацию объектного графа, этот тип отвечает за передачу в указанный поток следующей информации:

• абсолютных имен объектов графа (например, MyApp.JamesBondCar);

• имени компоновочного блока, определяющего объектный граф (например, MyApp.exe);

• экземпляра класса SerializationInfo, содержащего все данные, поддерживаемые членами объектного графа.

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

Замечание. Напомним, что SoapFormatter и XmlSerializer не сохраняют абсолютное имя типа и имя определяющего компоновочного блока. Эти типы заботятся только о сохранении открытых полей данных.

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

Рис. 17.3 Схема процесса сериализации

Кроме перемещения необходимых данных в поток и извлечения их из потока, средство форматирования (форматтер) анализирует члены объектного графа на наличие следующих элементов инфраструктуры.

• Выясняется, обозначен ли объект атрибутом [Serializable]. Если нет, то генерируется исключение SerializationException.

• Если объект обозначен атрибутом [Serializable], то выясняется, реализует ли объект интерфейс ISerializable. Если да, то для объекта вызывается GetObjectData().

• Если объект не реализует ISerializable, используется типовой процесс сериализации, сохраняются все поля, не обозначенные атрибутом [NonSerialized].

Вдобавок к выявлению поддержки типом интерфейса ISerializable, форматтеры (в .NET 2.0) отвечают также за выявление поддержки соответствующими типами членов, обозначенных атрибутами [OnSerializing], [OnSerialized], [OnDeserializing] или [OnDeserialized]. Роль этих атрибутов будет обсуждаться позже, a пока что мы рассмотрим роль ISerializable.

Настройка параметров сериализации с помощью ISerializable

Объекты, обозначаемые атрибутом [Serializable], имеют возможность реализовать интерфейс ISerializable. В этом случае вы можете "участвовать" в процессе сериализации, выполняя любое предварительное или последующее форматирование данных. Указанный интерфейс очень прост, поскольку он определяет единственный метод, GetObjectData().

// Для настройки процесса сериализации реализуйте ISerializable.

public interface ISerializable {

 void GetObjectData(SerializationInfo info, StreamingContext context);

}

Метод GetObjectData() вызывается форматтером в процессе сериализации автоматически. Реализация этого метода предоставляет через входной параметр SerializationInfo серию пар имен и значений, которые (обычно) соответствуют полям данных того объекта, который следует сохранить. Тип SerializationInfo определяет перегруженный метод AddValue(), имеющий множество вариаций, а также небольшой набор свойств, которые позволяют читать и устанавливать имя типа, имя определяющего компоновочного блока и значение счетчика членов. Вот фрагмент соответствующего программного кода.

public sealed class SerializationInfo: object {

 public SerializationInfo(Type type, IFormatterConverter converter);

 public string AssemblyName { get; set; }

 public string FullTypeName { get; set; }

 public int MemberCount { get; }

 public void AddValue(string name, short value);

 public void AddValue(string name, UInt16 value);

 public void AddValue(string name, int value);

 …

}

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

// Следует предложить пользовательский конструктор следующего вида, 

// чтобы среда выполнения могла установить состояние вашего объекта.

[Serializable]

class SomeClass: ISerializable {

 private SomeClass(SerializationInfo si, StreamingContext ctx) {…}

 …

}

Обратите внимание на то, что для области видимости этого конструктора указано private. Это вполне допустимо, поскольку форматтер получает доступ к этому члену независимо от его видимости. Эти специальные конструкторы чаще всего обозначаются как приватные, чтобы обеспечить невозможность случайного создания объекта пользователем объекта с помощью такого конструктора. Заметьте, что первый параметр этого конструктора является (как и ранее) экземпляром типа SerializationInfo.

Второй параметр этого специального конструктора является типом 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.

Когда клиенты и серверы обмениваются информацией через границы приложений, среда CLR вынуждена использовать низкоуровневые примитивы, обеспечивающие настолько "прозрачное" взаимодействие сторон, насколько это возможно. Это значит, что вам, как программисту .NET, не нужно создавать огромные по объему блоки программного кода поддержки сетевого соединения, чтобы вызвать метод удаленного объекта. Также и серверному процессу не нужно "вручную" извлекать сетевой пакет из очереди и преобразовывать сообщение в формат, понятный удаленному объекту. Вы вправе ожидать, что среда CLR позаботится о таких деталях сама, используя свой стандартный набор примитивов удаленного взаимодействия (хотя, при желании, вы тоже можете принять участие в установке параметров соответствующего процесса).

В сущности, слой удаленного взаимодействия .NET обеспечивает аккуратную совместную работу следующих четырех ключевых элементов:

• агенты;

• сообщения;

• каналы;

• форматтеры.

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

Агенты и сообщения

Клиенты и объекты сервера взаимодействуют не напрямую, а через посредника, обычно называемого агентом (или proxy-модулем). Роль агента .NET заключается в создании для клиента иллюзии того, что он взаимодействует с запрошенным удаленным объектом в одном домене приложения. Чтобы создать такую иллюзию, агент предлагает интерфейс (члены, свойства, поля и т.д.), идентичный интерфейсу удаленного типа. С точки зрения клиента данный агент и является удаленным объектом. Однако "за кулисами" агент переправляет вызовы удаленному объекту.

Формально такой агент, вызываемый клиентом непосредственно, называется прозрачным агентом (transparent proxy). Этот объект, генерируемый средой CLR автоматически, несет ответственность за проверку того, что при вызове удаленного метода клиент получит нужное число параметров (и они будут нужного типа). Поэтому прозрачный агент можно интерпретировать, как фиксированный слой взаимодействия, который нельзя программно изменить или расширить.

В предположении о том, что прозрачный агент может выполнять проверку входных аргументов, соответствующая информация упаковывается в другой генерируемый средой CLR тип, который называется объектом сообщения. По определению все объекты сообщений реализуют интерфейс System.Runtime.Remoting.Messaging.IMessage.

public interface IMessage {

 IDictionary Properties { get; }

}

Как видите, интерфейс IMessage определяет единственное свойство (с именем Properties), которое обеспечивает доступ к коллекции, используемой для хранения предоставленных клиентом аргументов. После наполнения объекта сообщения содержимым средой CLR, он будет передан родственному типу, называемому реальным агентом (real proxy).

Реальный, агент – это сущность, которая фактически посылает объект сообщения в канал (понятие канала будет обсуждаться ниже). Реальный агент, который (в отличие от прозрачного агента) может быть расширен программистом, представляется базовым типом класса с именем RealProxy (что и следовало ожидать). Снова следует подчеркнуть, что среда CLR генерирует клиентскую реализацию реального агента для использования по умолчанию, которая вполне подойдет вам если не во всех, то в большинстве случаев. Но чтобы иметь представление о функциональных возможностях, предлагаемых абстрактным базовым классом RealProxy, изучите формальное определение этого типа.

public abstract class RealProxy: object {

 public virtual ObjRef CreateObjRef(Type requestedType);

 publiс virtual bool Equals(object obj);

 public virtual IntPtr GetCOMIUnknown(bool fIsMarshalled);

 public virtual int GetHashCode();

 public virtual void GetObjectData(SerializationInfo info, StreamingContext context);

 public Type GetProxiedType();

 public static object GetStubData(RеаlРrоxу rp);

 public virtual object GetTransparentProxy();

 public Type GetType();

 public IConstructionReturnMessage InitializeServerObject(IConstructionCallMessage ctorMsg);

 public virtual IMessage Invoke(IMessage msg);

 public virtual void SetCOMIUnknown(IntPtr i);

 public static void SetStubData(RealProxy rp, object stubData);

 public virtual IntPtr SupportsInterface(ref Guid iid);

 public virtual string ToString();

}

Если вы не заняты построением пользовательской реализации реального агента клиента, то единственным интересным для вас членом будет RealProxy.Invoke(). С помощью метода Invoke() сгенерированный средой CLR прозрачный агент в фоновом режиме передает форматированный объект сообщения типу RealProxy.

Каналы

После того как агенты проверят и отформатируют поставляемые клиентом аргументы, упаковав их в объект сообщении, соответствующий IMessage-совместимый тип передается от реального агента объекту канала. Каналы – это сущности, отвечающие за транспортировку сообщения удаленному объекту и, если это необходимо, за то, чтобы возвращаемое значение от удаленного объекта было доставлено обратно клиенту. В библиотеках базовых классов .NET 2.0 предлагаются готовые реализации трех каналов:

• TCP-канал;

• HTTP-канал;

• IPC-канал.

TCP-канал представляется типом класса TcpChannel и используется для передачи сообщений с использованием сетевого протокола TCP/IP. Класс TcpChannel удобен тем, что форматированные пакеты оказываются исключительно "легкими", поскольку сообщения превращаются в плотный двоичный формат с помощью BinaryFormatter (да, именно того BinaryFormatter, о котором шла речь в главе 17). При использовании типа TcpChannel удаленный доступ осуществляется быстрее. Недостатком является то, что TCP-каналы не согласуются с брандмауэром автоматически и могут требовать вмешательства сервисов администратора системы, чтобы получить разрешение на пересечение границы машины.

В противоположность этому, HTTP-канал, представляемый типом класса HttpChannel, преобразует объекты сообщений в формат SOAP, используя для этого соответствующий форматтер SOAP. Выше вы могли убедиться в том, что SOAP опирается на XML и поэтому результат в данном случае оказывается более объемным, чем в случае TcpChannel. Поэтому при использовании HttpChannel удаленный доступ может осуществляться медленнее. Но, с другой стороны, протокол HTTP является гораздо более дружественным в отношении брандмауэра, поскольку большинство сетевых экранов позволяет текстовым пакетам направляться через порт с номером 80.

Наконец, в .NET 2.0 предлагается доступ к IPC-каналу, представленному типом IpcChannel, который определяет коммуникационный канал связи для удаленного взаимодействия с использованием IPC-архитектуры операционной системы Windows. Ввиду того, что IpcChannel при пересечении доменов приложений действует в обход традиционных систем сетевой коммуникации, IpcChannel оказывается намного быстрее, чем HTTP- и TCP-каналы, однако, может использоваться только для взаимодействия доменов приложения на одном и том же компьютере. Поэтому IpcChannel не может применяться для построения распределенных приложений, допускающих использование множества физических компьютеров. Но тип IpcChannel может оказаться идеальным вариантом тогда, когда вы хотите обеспечить наивысшую скорость обмена информацией между двумя локальными программами.

Важно понимать, что вне зависимости от типа канала, который вы выберете для использования, и HttpChannel, и TcpChannel, и IpcChannel реализуют интерфейсы IChannel, IChannelSender и IChannelReceiver. Интерфейс IChannel (как вы вскоре убедитесь) определяет небольшой набор членов, обеспечивающих общую функциональность всех типов каналов. Роль IChannelSender заключается в определении для каналов общего множества членов, позволяющих отправлять информацию данному получателю. С другой стороны, IChannelReceiver определяет множество членов, позволяющих каналу получать информацию данного отправителя.

Чтобы позволить приложениям клиента и сервера зарегистрировать выбранный ими канал, вы должны использовать метод ChannelServices.RegisterChannel(), который получит тип, реализующий IChannel. Вот фрагмент программного кода, который показывает, как домен серверного приложения может зарегистрировать HTTP-канал, использующий порт 32469 (аналогичные возможности клиента будут продемонстрированы чуть позже).

// Создание и регистрация HttpChannel-сервера с портом 32469.

HttpChannel c = new HttpChannel(32469); 

ChannelServices.RegisterChannel(с);

Снова о роли форматтера .NET

Заключительным элементом головоломки удаленного взаимодействия .NET является форматтер. Типы TcpChannel и HttpChannel используют свои внутренние форматтеры, задачей которых является перевод объекта сообщения в термины соответствующего протокола. Как уже говорилось, тип TcpChannel использует тип BinaryFormatter, в то время как тип HttpChannel использует функциональные возможности типа SoapFormatter. Опираясь на знания, полученные в предыдущей главе, вы должны понимать, как соответствующий канал форматирует поступающие сообщения.

После создания форматированного сообщения оно передается в канал, по которому в конце концов достигает целевого домена приложения. Там это сообщение преобразуется из специфических терминов протокола обратно в термины .NET, после чего элемент, который называется диспетчер, вызывает нужный метод удаленного объекта.

Общая картина

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

Рис. 18.1. Архитектура удаленного взаимодействия .NET, предлагаемая по умолчанию

Несколько слов о расширении стандартных возможностей

Ключевой особенностью слоя удаленного взаимодействия .NET является то, что большинство предлагаемых по умолчанию слоев удаленного взаимодействия может быть расширено или полностью заменено разработчиком приложения. Так, если вы хотите (или, возможно, вам нужно) построить диспетчер пользовательских сообщений, пользовательский форматтер или реальный агент, вы имеете для этого все возможности. Вы также можете добавить дополнительные слои, включив в цепочку обработки пользовательские типы (например, пользовательский приемник, используемый для предварительной или последующей обработки сообщений). Вам лично, возможно, никогда и не придется модифицировать базовый слой удаленного взаимодействия .NET, но факт в том, что платформа .NET предлагает пространства имен, позволяющие решить такую задачу.

Замечание. В этой главе тема расширения базового слоя удаленного взаимодействия .NET не обсуждается. Чтобы узнать, как это сделать, обратитесь к книге Ingo Rammer, Advanced .NET Remoting (Apress, 2002).

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

Варианты маршалинга для объектов: MBR и MBV

В рамках платформы .NET вы имеете на выбор два варианта того, как предоставить удаленный объект клиенту. Упрощенно говоря, маршалинг описывает правила передачи удаленного объекта из одного домена приложения в другой. При разработке объекта, предусматривающего удаленное использование, вы можете выбрать либо семантику MBR (marshal-by-reference – маршалинг по ссылке), либо семантику MBV (marshal-by-value – маршалинг по значению). Их различие заключается в следующем.

• MBR-объекты. Вызывающая сторона получает агента для осуществления доступа к удаленному объекту.

• MBV-объекты. Вызывающая сторона получает полную копию объекта для использования в своем домене приложения.

При использовании типа, относящегося к MBR-объектам, среда CLR обеспечит создание в домене приложения клиента прозрачного и реального агентов, в то время как сам MBR-объект будет оставаться в домене приложения сервера. При вызове методов удаленного типа клиентом система удаленного взаимодействия .NET (схема которой описана выше) активизируется, чтобы выполнить задачи упаковки, отправки и получения информации при обмене данными через границы доменов приложений. Для этого MBR-объекты имеют ряд свойств, "простирающихся" за рамки их физического расположения. Вы увидите, что MBR-объекты имеют различные опции конфигурации, относящиеся к их активизации и управлению циклом существования. В противоположность этому, MBV-объекты представляют собой локальные копии удалённых объектов (использующие протокол сериализации .NET, который был рассмотрен в главе 17). MBV-объекты имеют намного меньше опций конфигурации, поскольку их цикл существования контролируется непосредственно клиентом. Подобно любому другому объекту .NET, после того как клиент освободит все ссылки на MBV-тип, этот тип становится потенциальным объектом внимания для сборщика мусора. Поскольку MBV-типы являются локальными копиями удаленных объектов, процесс вызова клиентом членов соответствующего типа, вообще говоря, не предполагает никакой сетевой активности.

Следует понимать, что вполне естественным для сервера является поддержка доступа к множеству MBR- и MBV-типов. Вы можете также догадаться, что MBR-типы обычно поддерживают методы, возвращающие различные MBV-типы, что, в общем-то, напоминает автоматизированное предприятие, где один объект создает и выпускает другие связанные объекты. Здесь возникает следующий вопрос: как сконфигурировать пользовательский тип класса для использования в виде MBR-или MBV-объекта?

Процесс конфигураций объекта для использования в виде MBV-типа абсолютно аналогичен процессу конфигурации объекта для сериализации. Просто объявите соответствующий тип с атрибутом [Serializable].

[Serializable]

public class SportsCar {…}

MBR-объекты не маркируются специальным атрибутом .NET, а получаются (явно или неявно) из базового класса System.MarshalByRefObject.

public class SportsCarFactory: MarshalByRefObject {…}

Формально тип MarshalByRefObject определяется следующим образом.

public abstract class MarshalByRefObject: object {

 public virtual ObjRef CreateObjRef(Type requestedType);

 public virtual bool Equals(object obj);

 public virtual int GetHashCode();

 public virtual object GetLifetimeService();

 public Type GetType();

 public virtual object InitializeLifetimeService();

 public virtual string ToString();

}

Функциональные возможности, наследуемые от System.Object, вполне понятны, а роль остальных членов описана в табл. 18.2.

Таблица 18.2. Основные члены System.MarshalByRefObject

Можно сказать, что суть типа MarshalByRefObject заключается в определении членов, которые затем могут переопределяться для того, чтобы программно управлять циклом существования MBR-объекта (подробнее об управлении циклом существования объектов будет говориться в этой главе позже).

Замечание. То, что вы сконфигурировали тип в виде MBV- или MBR-объекта, совсем не означает, что этот объект следует использовать только в приложении удаленного взаимодействия, а означает только то, что этот объект можно использовать в таком приложении. Например, тип System.Windows.Forms.Form является потомком MarshalByRefObject. Поэтому при удаленном доступе он реализуется как MBR-тип, а в других случаях он будет обычным локальным объектом в домене приложения клиента.

Замечание. Как следствие предыдущего замечания обратим внимание на то, что если тип .NET не предполагает сериализацию и в его цепочке наследования нет MarshalByRefObject, то такой тип может активизироваться и использоваться только в его исходном домене приложения, т.е, такой тип является контекстно-связанным (см. главу 13).

Теперь, когда вы четко понимаете суть различий между MBR- и MBV-типами, давайте рассмотрим некоторые проблемы, специфичные для MBR-типов (к MBV-типам это не относится).

Варианты активизации для MBR-типа: WKO и CAO

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

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

• как общеизвестный объект (Well-Known Object – WKO);

• как объект, активируемый клиентом (Client Activated Object – CAO).

Замечание. Потенциальным источником недоразумений здесь является то, что в литературе, посвященной .NET, вместо акронима WKO также используют SAO (Server Activated Object – объект, активизируемый сервером). Акроним SAO встречается в целом ряде статей и книг, связанных с .NET. В этой главе, в соответствии с современной терминологией, будет использоваться аббревиатура WKO.

WKO-объекты – это MBR-типы, цикл существования которых подконтролен непосредственно домену приложения сервера. Приложение клиента активизирует удаленный тип, используя понятное общеизвестное строковое имя (отсюда и возник термин WKO). Домен приложения сервера размещает WKO-типы тогда, когда клиент выполняет первый вызов метода данного объекта (через прозрачный агент), а не тогда, когда программный код клиента использует ключевое слово new или когда вызов происходит через статический метод Activator.GetObject(), например:

// Получение агента для удаленного объекта.

// Эта строка не приводит к немедленному создании WKO-типа!

object remoteObj = Activator.GetObject(/* параметры… */);

// Вызов метода удаленного WKO-типа. Это приводит к созданию 

// WKO-объекта и вызову метода ReturnMessage().

RemoteMessageObject simple = (RemoteMessageObject)remoteObj;

Console. WriteLine("Сервер отвечает: {0}", simple.ReturnMуssage());

В чем здесь здравый смысл? При таком подходе простое предложение создать объект не ведет к немедленному пику сетевого обмена данными. Другим следствием является то, что WKO-типы могут создаваться только с помощью конструктора, заданного по умолчанию. Это разумно, поскольку конструктор удаленного типа используется только тогда, когда клиент выполняет вызов члена. Так что среда выполнения не имеет никакого иного варианта выбора, кроме вызова конструктора, заданного типом по умолчанию.

Замечание. Всегда помните о том, что любой WKD-тип должен иметь конструктор, заданный по умолчанию!

Если вы хотите разрешить клиенту создавать удаленные MBR-объекты с помощью пользовательского конструктора, сервер должен сконфигурировать соответствующий объект, как САО-объект. Цикл существования САО-объектов контролируется доменом приложения клиента. При доступе к САО-типу соответствующий обмен данными с сервером происходит уже при использовании клиентом ключевого слова new (с любым конструктором типа) или типа Activator.

Варианты конфигурации WKO-типа: синглеты и объекты одиночного вызова

Наконец, еще одна проблема выбора для MBR-типов в проекте .NET связана с тем, как сервер должен обрабатывать множественные обращения к WKO-типу. С САО-типами эта проблема не возникает, поскольку для них всегда есть однозначное соответствие между клиентом и удаленным САО-типом (эти типы являются объектами, кумулятивно изменяющими параметры своего состояния в процессе выполнения вызовов клиентов).

Одним из вариантов является конфигурация WKO-типа в виде синглета. В этом случае среда CLR создаст один экземпляр удаленного типа, который будет принимать запросы любого числа клиентов. Этот вариант оказывается естественным тогда, когда нужно поддерживать состояние типа, одинаковое для всех абонентов, выполняющих удаленные вызовы. Множество клиентов могут вызывать один и тот же метод в одно и то же время, поэтому среда CLR помещает каждый вызов клиента в новый поток. Однако обеспечение гарантий того, что ваши объекты будут реентерабельны, является вашей обязанностью, и для этого следует использовать подходы, описанные в главе 14,

В противоположность синглету, объект одиночного вызова - это WKO-тип, существующий только в контексте вызова отдельного метода. Поэтому, например, если WKO-тип, сконфигурированный с учетом семантики одиночного вызова, используется 20 клиентами, то сервер создаст 20 отдельных объектов (по одному для каждого клиента), и все эти объекты станут кандидатами для участия в процессе сборки мусора сразу же после завершения вызова метода. Как вы можете догадаться, объекты одиночного вызова, будучи объектами, не меняющими своего состояния, поддаются масштабированию лучше, чем синглеты.

Задача определения конфигурации состояния WKO-типа возлагается на сервер. Программно указанные варианты задаются с помощью перечня System.Runtime.Remoting.WellKnownObjectMode.

public enum WellKnownObjectMode {

 SingleCall,

 Singleton

}

Сводная характеристика MBR-объектов

Вы имели возможность убедиться в том, что для конфигурации MBV-объек-тов долгих размышлений не потребуется: нужно просто применить атрибут [Serializable], чтобы позволить отправку копий соответствующего типа в домен приложения клиента. С этого момента все взаимодействие с MBV-типом происходит в локальном окружении клиента. Когда клиент завершит использование соответствующего MBV-типа, этот тип становится объектом внимания сборщика мусора, и никаких проблем не возникает.

Но для MBR-типов имеется целый ряд вариантов конфигурации. Вы видели, что MBR-тип допускает варианты конфигурации в отношении его времени активизации, состояния и управления циклом существования. Чтобы представить весь набор имеющихся возможностей, в табл. 18.3 показано, как WKO и САО-объекты соотносятся с вариантами поведения, которые только что были нами рассмотрены.

Таблица 18.3. Опции конфигурации для MBR-типов

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

• общий компоновочный блок с именем SimpleRemotingAsm.dll;

• компоновочный блок клиента с именем SimpleRemoteObjectClient.exe;

• компоновочный блок сервера с именем SimpleRemoteObjectServer.exe.

Создание общего компоновочного блока

Сначала создадим общий компоновочный блок, SimpleRemotingAsm.dll, на который будут ссылаться как сервер, так и клиент. В SimpleRemotingAsm.dll определяется единственный MBR-тип с именем RemoteMessageObject, который поддерживает два открытых члена. Метод DisplayMessage() выводит в окно консоли сервера поставляемое клиентом сообщение, a ReturnMessage() возвращает некоторое сообщение клиенту. Вот полный программный код этой новой библиотеки классов C#.

namespace SimpleRemotingAsm {

 // Для этого типа при удаленном доступе

 // будет иcпользоваться маршалинг до ссылке (MBR).

 public class RemoteMessageObject: MarshalByRefObject {

  public RemoteMessageObject() { Console.WriteLine("Создание RemoteMessageObject!"); }

  // Этот метод получает входную строку

  // от вызывающей стороны.

  public void DisplayMessage(string msg) { Console.WriteLine("Сообщение: {0}", msg); }

 // Этот метод возвращает значение вызывающей стороне.

 public string ReturnMessage() { return "Привет от сервера!"; }

 }

}

Наиболее интересным здесь является то, что соответствующий тип получается из базового класса System.MarshalByRefObject, в результате чего полученный класс будет гарантированно доступным с помощью агента на стороне клиента. Также обратите внимание на пользовательский вариант конструктора, заданного по умолчанию, который печатает сообщение при создании экземпляра типа. Вот и все. Теперь можете создать новый компоновочный блок SimpleRemotingAsm.dll на базе этого программного кода.

Создание компоновочного блока сервера

Напомним, что компоновочные блоки сервера обслуживают, в частности, и общие компоновочные блоки, содержащие объекты удаленного доступа. Создайте консольную программу с именем SimpleRemoteObjectServer. Роль серверного компоновочного блока заключается в том, чтобы открыть канал для поступающих запросов и зарегистрировать RemoteMessageObjесt, как WKO-объект. Сначала сошлитесь на компоновочные блоки System.Runtime.Remoting.dll и SimpleRemotingAsm.dll и обновите Main() так, как предлагается ниже.

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using SimpleRemotingAsm;

namespace SimpleRemoteObjectServer {

 class SimpleObjServer {

  static void Main(string[] args) {

  Console.WriteLine("*** Начало работы SimpleRemoteObjectServer! ***");

   Console.WriteLine("Для завершения нажмите ‹Enter›");

  // Регистрация нового HttpChannel

  HttpChannel с = new HttpChannel(32469);

   ChannelServices.RegisterChannel(c);

  // Регистрация WKO-типа с активацией синглета.

  RemotingConfiguration.RegisterWellKnownServiceType(typeof(SimpleRemotingAsm.RemoteMessageObject), "RemoteMsgObj.soap", WellKnownObjectMode.Singleton); 

  Console.ReadLine();

  }

 }

}

Метод Main() начинается c создания нового типа HttpChannel, для которого указан произвольный идентификатор порта. Этот порт открывается путем регистрации канала с помощью статического метода ChannelServices.RegisterChannel(). После регистрации канала компоновочный блок удаленного сервера может обрабатывать сообщения, поступающие через порт с номером 32469.

Замечание. Номер, который вы назначите порту, как правило, выбираете вы сами (или ваш системный администратор). При этом, однако, следует учитывать то, что порты с номерами ниже 1024 резервируются для использования системой.

Затем, чтобы зарегистрировать тип SimpleRemotingAsm.RemoteMessageObject в качестве WKO-типа, используется метод RemotingConfiguration.RegisterWellKnownServiceType(). Первым аргументом этого метода является информация типа для регистрируемого типа. Вторым параметром RegisterWellKnownServiceТуре() является произвольная выбранная вами строка, которая будет использоваться для идентификации регистрируемого объекта при обмене данными между доменами приложений. Здесь вы информируете среду CLR о том, что данный объект должен распознаваться клиентом по имени RemoteMsgObj.soap.

Заключительным параметром является член перечня WellKnownObjectMode, и для него здесь указано WellKnownObjectMode.Singleton. Напомним, что при использовании WKO-синглета все поступающие запросы обслуживаются одним экземпляром RemoteMessageObject. Создайте компоновочный блок сервера и переходите к созданию программного кода клиента.

Создание компоновочного блока клиента

Теперь, когда у вас есть приемник, который будет обслуживать объекты уда-ленного доступа, остается создать компоновочный блок, который запросит доступ к соответствующим возможностям. Здесь снова создайте простое консольное приложение. Установите ссылку на System.Runtime.Remoting.dll и SimpleRemotingAsm.dll. Реализуйте Main() так, как показано ниже.

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using SimpleRemotingAsm;

namespace SimpleRemoteObjectClient {

 class SimpleObjClient {

  static void Main(string[] args) {

  Console.WriteLine("*** Начало работы SimpleRemoteObjectClient! ***");

   Console.WriteLine("Для завершения нажмите ‹Enter›");

  // Создание нового HttpChannel.

  HttpChannel с = new HttpChannel();

   ChannelServices.RegisterChannel(c);

  // Получение агента для удаленного доступа к WKO-типу.

  object remoteObj = Activator.GetObject(typeof(SimpleRemotingAsm.RemoteMessageObject), "http://localhost:32469/RemoteMsgObj.soap");

  // Использование удаленного объекта.

  RemoteMessageObject simple = (RemoteMessageObject)remoteObj;

   simple.DisplayMessage("Привет от клиента!");

   Console.WriteLine("Сервер говорит: {0}", simple.ReturnMessage());

   Console.ReadLine();

  }

 }

}

В этом приложении клиента обратите внимание на следующее. Во-первых, клиент также должен зарегистрировать HTTP-канал, но идентификатор порта при этом не указывается, поскольку конечная точка канала задается адресом URL активизации, поставляемым клиентом. Поскольку клиент взаимодействует с WKO-типом, вы должны активизировать конструктор типа, заданный по умолчанию. С этой целью вызывается метод Activator.GetObject() с двумя параметрами. Первым параметром является информация типа удаленного объекта, с которым вы хотите взаимодействовать. Прочитайте последнее предложение еще раз. Поскольку здесь метод Activator.GetObject() требует метаданные описания объекта, становится ясно, почему для клиента также требуется ссылка на общий компоновочный блок! В конце главы будут рассмотрены различные возможности совершенствования поведения компоновочного блока клиента в этом отношении.

Второй параметр метода Activator.GetObject() представляет собой URL активизации. Значение URL активизации, описывающее WKO-тип, можно представить в следующем обобщенном формате.

СхемаПротокола://ИмяКомпьютера:Порт/UriОбъекта

Наконец, заметим, что метод Activator.GetObject() возвращает общий тип System.Object, поэтому для получения доступа к членам RemoteMessageObject необходимо использовать явное преобразование типа.

Тестирование приложения, использующего удаленное взаимодействие

При тестировании приложения начните с запуска серверного приложения, которое откроет HTTP-канал и зарегистрирует объект RemoteMessageObject для удаленного доступа. Затем запустите экземпляр приложения клиента. Если все пройдет хорошо, окно вашего сервера должно иметь вид, показанный на рис. 18.2, а приложение клиента должно отображать то, что вы видите на рис. 18.3.

Рис. 18.2. Вывод сервера

Рис. 18.3. Вывод клиента

Итак, вы успешно построили распределённое приложение, используя слой удаленного взаимодействия .NET. В связи c данными примерами следует обратить внимание на то что полученные приложения клиента и сервера содержат большой объем "жестко" кодируемой программной логики. Например, сервер указывает фиксированный идентификатор порта, фиксированный режим активизации и фиксированный тип канала. Клиент, с другой стороны, "жестко" кодирует имя удаленного объекта, с которым пытается взаимодействовать.

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

Вспомните из главы 11 о том, что файл *.config можно использовать для "подсказок" среде CLR в отношений места нахождения внешних компоновочных блоков, необходимых для работы приложения. Эти же файлы *.config могут использоваться и для информирования CLR о целом ряде параметров удаленного взаимодействия, как на стороне клиента, так и на стороне сервера.

При создании файла *.config для указания различных параметров удаленного взаимодействия используют элемент ‹system.runtime.remoting›. Если у вашего приложения уже есть файл *.config, в котором указаны параметры размещения компоновочного блока, вы можете добавить элементы удаленного взаимодействия в этот же файл. Единый файл *.config, содержащий и настройки удаленного взаимодействия, и информацию привязки, должен выглядеть примерно так.

‹configuration›

 ‹sуstem.runtime.remoting›

  ‹!-- параметры удаленного взаимодействия клиента и сервера --›

 ‹/system.runtime.remoting›

 ‹runtime›

  ‹!-- информация привязки компоновочного блока --›

 ‹/runtime›

‹/configuration›

Если вам нечего указать в отношении привязки компоновочного блока, вы можете опустить соответствующий элемент ‹runtime› и использовать в файле *.config шаблон следующего вида.

‹configuration›

 ‹system.runtime.remoting›

 ‹!-- параметры удаленного взаимодействия клиента и сервера --›

 ‹/system.runtime.remoting›

‹/configuration›

Создание файлов *.config сервера

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

// "Жестко" заданная программная логика сервера HTTP.

HttpChannel с = new HttpChannel(32469); 

ChannelServices.RegisterChannel(с); 

RemotingConfiguration.RegisterWellKnownServiceType(typeof(SimpleRemotingAsm.RemoteMessageObject), "RemoteMsgObj.soap", WellKnownObjectMode.Singleton);

Используя элементы ‹service›, ‹wellknown› и ‹channels›, эту программную логику можно заменить следующим файлом *.config.

‹configuration›

 ‹system.runtime.remoting›

 ‹application›

   ‹service›

   ‹wellknown mode="Singleton" type="SimpleRemotingAsm.RemoteMessageObject, SimpleRemotingAsm" objectUri="RemoteMsgObj.soap"/›

  ‹/service›

  ‹channels›

   ‹channelref="http"/›

  ‹/channels›

  ‹/application›

 ‹/system.runtime.remoting›

‹/configuration›

Обратите внимание на то, что значительная часть информации удаленного сервера указывается в контексте элемента ‹service› (не сервер!). Его дочерний элемент ‹wellknown› использует три атрибута (mode, type и objectUri) для регистрации WKO-объекта в слое удаленного взаимодействия .NET. Элемент ‹channels› может содержать любое число элементов ‹channel›, которые позволяют определить вид канала (в данном случае это HTTP), открываемого на сервере. Для ТСР-каналов вместо http нужно просто использовать лексему tcp.

Поскольку в этом случае вся необходимая информация содержится в файле SimpleRemoteObjectServer.exe.config, метод Main() серверной стороны значительно упрощается. В нем остается выполнить только вызов RemotingConfiguration.Configure() и указать имя соответствующего файла конфигурации.

static void Main(string[] args) {

 // Регистрация WKO-объекта с помощью файла *.config.

 RemotingConfiguration.Configure("SimpleRemoteObjectServer.exe.config");

 Console.WriteLine("Старт сервера! Для остановки нажмите ‹Enter›");

 Console.ReadLine();

}

Создание файлов *.config клиента

Клиенты тоже могут использовать файлы *.config удаленного взаимодействия. В отличие от файлов конфигурации сервера, в файлах конфигурации клиента для идентификации имени WKO-объекта используется элемент ‹client›. Вдобавок к возможности динамического изменения параметров удаленного взаимодействия без перекомпиляции базового программного кода, файлы *.config клиента позволяют создать тип агента непосредственно с помощью ключевого слова C# new, не используя метод Activator.GetObject(). Предположим, например, что у нас есть файл *.config клиента со следующим содержимым.

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

  ‹client displayName = "SimpleRemoteObjectClient"›

   ‹wellknown type=" SimpleRemotingAsm.RemoteMessageObject, SimpleRemotingAsm" url="http://localhost:32469/RemoteMsgObj.soap"/›

  ‹/client›

  ‹channels›

   ‹channel ref="http"/›

  ‹/channels›

  ‹/application›

 ‹/system.runtime.remoting›

‹/configuration›

Тогда можно изменить метод Main() клиента так.

statiс void Main(string[] args) {

 RemotingConfiguration.Configure("SimpleRemoteObjectClient.exe.config");

 // При использовании файла *.config клиент может создать тип

 // непосредственно с помощью ключевого слова 'new' .

 RemoteMessageObject simple = new RemoteMessageObject();

 simple.DisplayMessage("Привет от клиента!");

 Console.WriteLine("Сервер говорит: {0}", simple.ReturnMessage());

 Console.WriteLine("Старт клиента! Для остановки нажмите ‹Enter›");

 Console.ReadLine();

}

При выполнении этого варианта приложения вывод оказывается аналогичным исходному. Если клиент пожелает использовать TCP-канал, то для свойств url элемента ‹wellknown› и ref элемента ‹сhannel› следует вместо http указывать tcp.

Исходный код. Проекты SimpleRemoteObjectServerWithConfig и SimpleRemoteObjectClientWithConfig размещены в подкаталоге, соответствующем главе 18 (оба эти проекта используют созданный выше компоновочный блок SimpleRemotingAsm.dll).

Наши первые приложения удаленного взаимодействия позволяли доступ клиентов к одному WKO-типу. Напомним, что WKO-типы (по определению) являются MBR-типами, поэтому доступ клиента к ним осуществляется через агента-посредника. В противоположность этому, MBV-типы являются локальными копиями серверного объекта, обычно возвращаемыми открытыми членами некоторого MBR-типа. Вы уже знаете, как настроить MBV-тип (следует обозначить соответствующий класс атрибутом [Serializable]), но MBV-тип в действии вы еще не видели (если не считать обмена строковыми данными между двумя сторонами). Для иллюстрации взаимодействия MBR- и MBV-типов мы рассмотрим новый пример, в котором используются следующие три компоновочных блока.

• Общий компоновочный блок CarGeneralAsm.dll

• Компоновочный блок клиента CarProviderClient.exe

• Компоновочный блок сервера CarProviderServer.exe

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

Создание общего компоновочного блока

В ходе нашего обсуждения процесса сериализации объектов в главе 17 мы создали тип JamesBondCar (в дополнение к связанным классам Radio и Car). Библиотека программного кода CarGeneralAsm.dll будет использовать эти типы, поэтому сначала выберите Projects→Add Existing Item из меню и добавьте в свой новый проект библиотеки классов соответствующие файлы *.cs (автоматически созданный файл Class1.cs можете удалить), Поскольку каждый из добавленных типов уже обозначен атрибутом [Serializable], они готовы для маршалинга по значению в отношении удаленного клиента.

Теперь нам нужен MBR-тип, который обеспечит доступ к типу JamesBondCar. Чтобы сделать ситуацию немного более интересной, ваш MBR-объект (CarProvider) будет поддерживать обобщенный список List‹› типов JamesBondCar. Тип CarProvider определит два члена, которые позволят вызывающей стороне получить заданный тип JamesBondCar, а также полный перечень List‹› соответствующих типов. Вот весь программный код для нового типа класса.

namespace CarGeneralAsm {

 // Этот тип является MBR-объектом, обеспечивающим доступ

 // к соответствующим MBV-типам.

 public class CarProvider: MarshalByRefObject {

  private List‹JamesBondCar› theJBCars = new List‹JamesBondCar›();

  // Добавление в список нескольких машин.

  public CarProvider() {

  Console.WriteLine("Создание поставщика машин");

  theJBCars.Add(new JamesBondCar("QMobile", 140, true, true"));

  theJBCars.Add(new JamesBondCar("Flyer", 140, true, false));

  theJBCars.Add(new JamesBondCar("Swimmer", 140, false, true));

  theJBCars.Add(new JamesBondCar("BasicJBC", 140, false, false));

  }

  // Получение всех JamesBondCar.

  public List‹JamesBondCar› GetAllAutos() { return theJBCars; }

  // Получение одного JamesBondCar,

  public JamesBondCar GetJBCByIndex(int i) { return (JamesBondCar)theJBCars[i]; }

 }

}

Обратите внимание на то, что метод GetAllAutos() возвращает внутренний тип List‹›. Очевидный вопрос: как данный член пространства имен System. Collections.Generic представляется вызывающей стороне? Если посмотреть описание этого типа в документации .NET Framework 2.0 SDK, вы обнаружите, что list‹› сопровождается атрибутом [Serializable].

[SerializableAttribute()] 

public class List‹T›: IList, ICollection, IEnumerable

Таким образом, для всего содержимого типа List‹› будет использован маршалинг по значению (если содержащиеся в нем типы также допускают сериализацию). Это очень удобная особенность удаленного взаимодействия .NET и членов библиотек базовых классов. Вдобавок к пользовательским MBV- и MBR-типам, которые вы можете создать сами, любой тип из библиотек базовых классов, сопровождающийся атрибутом [Serializable], также способен выступать в качестве MBV-типа в архитектуре удаленного взаимодействия .NET. Аналогично, любой тип, получающийся (непосредственно или косвенно) из MarshalByRefObject, может функционировать, как MBR-тип.

Замечание. Следует знать о том, что SoapFormatter не поддерживает сериализацию обобщенных типов. При создании методов, получающих или возвращающих обобщенные типы (напри-мер, List‹›), вы должны использовать BinaryFormatter и объект TcpChannel.

Создание компоновочного блока сервера

Компоновочный блок сервера (CarProviderServer.exe) в рамках метода Main() содержит следующую программную логику.

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using CarGeneralAsm;

namespace CarProviderServer {

 class CarServer {

  static void Main(string[] args) {

  RemotingConfiguration.Configure("CarProviderServer.exe.config");

   Console.WriteLine("Старт сервера! Для остановки нажмите ‹Enter›");

  Console.ReadLine();

 }

 }

}

Соответствующий файл *.config почти идентичен файлу *.config сервера, созданному в предыдущем примере. Единственным заслуживающим внимания моментом здесь является определение значения URI объекта для типа CarProvider.

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

   ‹service›

   ‹wellknown mode="Singleton" type="CarGeneralAsm.CarProvider, CarGeneralAsm" objectUri="carprovider.rem" /›

   ‹/service›

   ‹channels›

   ‹channel ref="tcp" port="32469" /›

   ‹/channels›

 ‹/application›

 ‹/system.runtime.remoting› 

‹/configuration›

Создание компоновочного блока клиента

Наконец, рассмотрим приложение клиента, которое будет использовать MBR-тип CarProvider для получения отдельных типов JamesBondCars и типа List‹›. После получения типа от CarProvider вы посылаете его вспомогательной функции UseCar() для обработки.

using System;

using System.Runtime.Remoting;

using System.Runtime.Remoting.Channels;

using System.Runtime.Remoting.Channels.Http;

using CarGeneralAsm;

using System.Collections.Generic;

namespace CarProviderClient {

 class CarClient {

  private static void UseCar(JamesBondCar c) {

  Console.WriteLine("-› Имя: {0}", с.PetName);

  Console.WriteLine("-› Макc. скорость: {0} ", с.MaxSpeed);

  Console.WriteLine("-› Способность плавать: {0}", с.isSeaWorthy);

   Console.WriteLine("-› Способность летать: {0}, c.isFlightWorthy);

   Console.WriteLine();

  }

  static void Main(string[] args) {

  RemotingConfiguration.Configure("CarProviderClient.exe.config");

  // Создание поставщика машин.

  CarProvider cр = new CarProvider();

  // Получение первого объекта JBC.

  JamesBondCar qCar = cp.GetJBCByIndex(0);

  // Получение всех объектов JBC.

  List‹JamesBondCar› allJBCs = cp.GetAllAutos();

  // Использование первой машины.

  UseCar(gCar);

  // Использование всех машин в List‹›.

  foreach(JamesBondCar j in allJBCs) UseCar(j);

   Console.WriteLine(''Старт клиента! Для остановки нажмите ‹Enter›");

  Console.ReadLine();

  }

 }

}

Содержимое файла *.config на стороне клиента также соответствует ожиданиям. Здесь нужно просто изменить URL активизации.

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

  ‹client displayName = "CarClient"›

   ‹wellknown type= "CarGeneralAsm.CarProvider, CarGeneralAsm" url="tcp://localhost:32469/carpovider.rem"/›

   ‹/client›

   ‹channels›

   ‹channel ref="http" /›

   ‹/channels›

 ‹/application›

 ‹/system.runtime.remoting› 

‹/configuration›

Теперь запустите свои приложения сервера и клиента (конечно же, в указанном порядке) и рассмотрите соответствующий вывод. В окне консоли клиента будут представлены объекты JamesBondCar и соответствующая информация для каждого типа. Напомним, что вы взаимодействуете с List‹› и типами JamesBondCar, поэтому вы работаете с их членами в рамках домена приложения клиента, так как оба указанных типа обозначены атрибутом [Serializable].

Чтобы доказать это, измените вспомогательную функцию UseCar() так, чтобы она вызывала метод TurnOnRadio() для входного объекта JamesBondCar. Теперь запустите приложения сервера и клиента еще раз. Обратите внимание на то, что на машине клиента теперь появляются соответствующие сообщения. Если бы типы Car, Radio и JamesBondCar были сконфигурированы, как MBR-типы, сообщения бы появлялись на сервере. Для проверки получите каждый из указанных типов из MarshalByRefObject и перекомпилируйте все три компоновочных блока (для гарантии того, что Visual Studio 2005 скопирует самый последний CarGeneralAsm.dll в каталоги приложений клиента и сервера). Теперь при выполнении приложения окно с сообщением появится на удаленной машине.

Исходный код. Проекты CarGeneralAsm, CarProviderServer и CarProviderClient размещены в подкаталоге, соответствующем главе 18.

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

С другой стороны, САО-типы, а также WKO-типы, сконфигурированные для активизации в виде синглета, являются по своей природе объектами, кумулятивно изменяющими параметры своего состояния в процессе выполнения вызовов клиентов. Учитывая эти две доступные опции установки конфигурации, возникает следующий вопрос: как процесс сервера "узнает" о том, что пора уничтожить такой MBR-объект? Если сборщик мусора на сервере уничтожит MBR-объекты, находящиеся в использовании удаленным клиентом, это создаст проблемы, А если серверу придется ожидать освобождения MBR-типов слишком долго, это отрицательно повлияет на работу системы, особенно если соответствующие MBR-объекты удерживают важные ресурсы (связь с базой данных, неуправляемые типы или какие-то другие ресурсы).

Цикл существования MBR-объекта, являющегося CAO-типом или WKD-синглетом, контролируется по схеме лизингового управления, которая тесно связана с процессом сборки мусора .NET. Если "время аренды" MBR-объекта, являющегося CAO типом или WKO-синглетом истекает, объект становится кандидатом на участие в очередном цикле сборки мусора. Как и в случае любого другого .NET-типа, если удаленный объект переопределяет System.Object.Finalize() (с помощью синтаксиса деструктора C#), то среда выполнения .NET автоматически запустит соответствующую логику финализации.

Схема лизингового управления, используемая по умолчанию

Для MBR-объектов, являющихся САО-типами или WKO-синглетами, применяется так называемый лизинг по умолчанию, время которого равно пяти минутам. Если среда выполнения обнаружит, что MBR-объект, являющийся САО-типом или WKO-синглетом, остается неактивным в течение пяти минут, делается вывод о том, что клиент больше не использует данный удаленный объект, и поэтому этот объект может использоваться в процессе сборки мусора. При этом совсем не обязательно, чтобы после истечения времени лизинга объект помечался для сборки мусора немедленно. На самом деле есть много возможностей влиять на поведение, задаваемое лизингом по умолчанию.

Например, при каждом вызове клиентом члена удаленного MBR-обьекта, являющегося САО-типом или WKO-синглетом, время лизинга снова устанавливается равным пяти минутам. Но кроме автоматического обновления интервала времени лизинга при вызове клиента, среда выполнения .NET обеспечивает три дополнительные альтернативы.

• Установки лизинга по умолчанию для удаленных объектов могут переопределяться файлами *.config.

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

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

Мы рассмотрим каждую из указанных возможностей в следующих разделах, а пока что давайте рассмотрим установки лизинга, принятые для удаленного типа по умолчанию. Вспомните, что базовый класс MarshalByRefObject определяет член с именем GetLifetimeService(). Этот метод возвращает ссылку на внутренний объект, поддерживающий интерфейс System.Runtime.Remoting.Lifetime.ILease. Интерфейс ILease можно использовать для управления параметрами лизинга данного САО-типа или WKO-синглета. Вот формальное определение этого интерфейса.

public interface ILease {

 TimeSpan CurrentLeaseTime { get; }

 LeaseState CurrentState { get; }

 TimeSpan InitialLeaseTime { get; set; }

 TimeSpan RenewOnCallTime { get; set; }

 TimeSpan SponsorshipTimeout { get; set; }

 void Register(System.Runtime.Remoting.Lifetime.ISponsor obj);

 void Register(System.Runtime.Remoting.Lifetime.ISponsor obj, TimeSpan renewalTime);

 TimeSpan Renew(TimeSpan renewalTime);

 void Unregister(System.Runtime.Remoting.Lifetime.ISponsor obj);

}

Интерфейс ILease не только позволяет получить информацию о текущих параметрах лизинга (с помощью CurrentLeaseTime, CurrentState и InitialLeaseTime), но и обеспечивает возможность построения "спонсоров" лизинга (более подробно об этом будет говориться позже). Роль каждого из членов ILease описана в табл. 18.6.

Таблица 18.6. Члены интерфейса ILease

Для иллюстрации особенностей лизинга по умолчанию для удаленных СAО-типов и WKO-синглетов определим в нашем текущем проекте CAOCarGeneralAsm новый внутренний класс LeaseInfo. Статический член LeaseStats() этого класса выводит информацию о текущем лизинге для типа CarProvider в окно консоли сервера (не забудьте указать директиву using для пространства имен System.Runtime.Remoting.Lifetime, чтобы сообщить компилятору о месте нахождения определении типа ILease).

internal class LeaseInfo {

 public static void LeaseStats(ILease itfLease) {

 Console.WriteLine(***** Информация о лизинге *****");

 Console.WriteLine("Состояние лизинга: {0}", itfLease.CurrentState);

 Console.WriteLine("Начальное время лизинга: {0}:{1}", itfLease.InitialLeaseTime.Minutes, itfLease.InitialLeaseTime.Seconds);

 Console.WriteLine("Текущее время лизинга: {0}:{1}", itfLease.CurrentLeaseTime.Minutes, itfLease.CurrentLeaseTime.Seconds);

 Console.WriteLine("Обновление времени при вызове: {0}:{1}", itfLease.RenewOnCallTime.Minutes, itfLease.RenewOnCallTime.Seconds);

 Console.WriteLine();

 }

}

Теперь предположим, что LeaseInfo.LeaseStats() вызывается в рамках методов GetJBCByIndex() и GetAllAutos() типа CarProvider. После перекомпиляции компоновочных блоков сервера и клиента (снова для гарантии того, что система Visual Studio 2005 скопирует самую последнюю и наиболее полную версию CarGeneralAsm.dll в каталоги приложений клиента и сервера), выполните приложение еще раз. Окно консоли вашего сервера должно теперь быть похожим на то, которое показано на рис. 18.6.

Рис. 18.6. Информация лизинга по умолчанию для CarProvider

Изменение параметров схемы лизингового управления

Очевидно, параметры лизинга по умолчанию не могут годиться во всех случаях и для всех удаленных САО-объектов и WKO-синглетов. Если вы хотите изменить типовые установки, у вас на выбор есть два варианта.

• Установки лизинга, принятые по умолчанию, можно изменить с помощью файла *.config сервера.

• Установки лизинга, принятые по умолчанию, можно изменить программными средствами путем переопределения членов базового класса MarshalByRefObject.

Каждый из этих подходов действительно позволяет изменить установки лизинга, принятые по умолчанию, но между этими подходами есть принципиальная разница. При использовании файла *.config сервера установки лизинга применяются ко всем объектам, размещаемым в рамках процесса сервера. При переопределении отдельных членов типа MarshalByRefObject появляется возможность изменять установки лизинга для каждого объекта в отдельности.

Чтобы продемонстрировать изменение параметров лизинга по умолчанию с помощью файла *.config, добавим к XML-данным сервера дополнительный элемент ‹lifetime›.

‹configuration›

 ‹system.runtime.remoting›

 ‹application›

  ‹lifetime leaseTime = "15M" renewOnCallTime = "5M"/›

  ‹service›

   ‹activated type="CarGeneralAsm.CarProvider, CarGeneralAsm" /›

  ‹/service›

  ‹channels›

   ‹channel ref="tcp" port="32469" /›

  ‹/channels› 

  ‹/application 

 ‹/system.runtime.remoting›

‹/configuration›

Обратите внимание на то, что в значениях свойств leaseTime и renewOnCallTime используется суффикс M, который, как вы можете догадаться сами, при установке времени для лизинга обозначает использование минут в качестве единицы измерения. При необходимости числовые значения элемента ‹lifetime› могут также содержать суффиксы MS (миллисекунды), S (секунды), Н (часы) и даже D (дни).

Повторим, что при изменении файла *.config сервера вы изменяете параметры лизинга для каждого САО-объекта и WKO-синглета в рамках сервера. Как альтернативу, можно использовать программное переопределение метода InitializeLifetime() конкретного удаленного типа.

public class CarProvider: MarshalByRefObject {

 public override object InitializeLifetimeService() {

 // Получение текущей информации лизинга.

 ILease itfLeaseInfo = (ILease)base.InitializeLifetimeService();

 // Изменение установок.

 itfLeaseInfo.InitialLeaseTime = TimeSpan.FromMinutes(50);

 itfLeaseInfo.RenewOnCallTime = TimeSpan.FromMinutes(10);

 return itfLeaseInfo;

 }

 …

}

Здесь CarProvider устанавливает значение 50 минут для InitialLeaseTime и значение 10 – для RenewOnCallTime. Снова подчеркнем, что преимуществом переопределения метода InitializeLifetimeServices() является возможность, настройки каждого удаленного типа в отдельности.

Наконец, чтобы вообще отключить ограничения для времени лизинга данного СAО-типа или WKO-синглета, переопределите InitializeLifetimeServices() так, чтобы возвращалось значение null. В результате вы, по сути, укажете МВR-тип, который будет существовать всё время, пока будет работать хост-приложение сервера.

Настройка параметров лизинга на стороне сервера

Вы только видели, что переопределение метода InitializeLifetimeServices() MBR-типом позволяет изменить текущие параметры лизинга во время активизации типа. Но что делать, если удаленному типу нужно изменить параметры лизинга после активизации? Предположим, например, что тип CarProvider предлагает новый метод, выполняющий операцию, требующую много времени (например; соединение с удаленной базой данных с последующим чтением большого набора записей). Перед началом выполнения такого заданий вы можете программно изменить время лизинга так, чтобы в случае, когда остаток времени становится менее одной минуты, время лизинга снова увеличивалось до десяти минут. Для этого можно использовать наследуемые методы MarshalByRefObject.GetLifetimeService() и ILease.Renew() так, как предлагается ниже.

// Корректировка параметров лизинга на стороне сервера. 

// Предполагается, что это новый метод типа CarProvider.

public void DoLengthyOperation() {

 ILease itfLeaseInfo = (ILease)this.GetLifetimeService();

 if (itfLeaseInfo.CurrentLeaseTime.TotalMinutes ‹ 1.0) itfLeaseInfo.Renew(TimeSpan.FromMiutes(10));

 // Выполнение длительной операции…

}

Настройка параметров лизинга на стороне клиента

В дополнение к указанным возможностям ILease, домен приложения клиента тоже может регулировать текущие параметры лизинга CAO-типов и WKD-сингле-тов, с которыми осуществляется удаленное взаимодействие. Для этого клиент должен использовать статический метод RemotingServices.GetLifetimeService(). В качестве параметра указанному члену клиент должен передать ссылку на удаленный тип так, как показано ниже.

// Корректировка параметров лизинга на стороне клиента.

CarProvider ср = new CarProvider(сars);

ILease itfLeaseInfo = (ILease)RemotingServices.GetLifetimeServiсе(cp); 

if (itfLeaseInfo.CurrentLeaseTime.TotalMinutes ‹ 10.0) itfLeaseInfo.Renew(TimeSpan.FromMinutes(1000));

Такой подход может быть полезен тогда, когда домен приложения клиента готов начать выполнение длительной операции в потоке, использующем удаленный тип. Например, если однопоточное приложение должно напечатать документ, содержащий 100 страниц текста, очень велика вероятность того, что удаленный САО-тип или WKO-синглет может выйти за рамки отведенного для процесса времени. Надеюсь, вы уловили общую идею, хотя здесь, конечно, более "элегантным" решением является создание нового потока выполнения.

При изучении материала этой главы вы создали группу консольных серверных хостов, обеспечивающих доступ к некоторому множеству удаленных объектов. Если вы имеете опыт использования классической модели DCOM (Distributed Component Object Model – распределенная модель компонентных объектов), соответствующие шаги могут показаться вам немного странными. В мире DCOM обычно строится один COM-сервер (на стороне сервера), содержащий удаленные объекты, который несет ответственность и за прием запросов, поступающих от удаленного клиента. Это единственное DCOM-приложение *.exe "спокойно" загружается в фоновом режиме без создания, в общем-то ненужного командного окна.

При построении компоновочного блока сервера .NET велика вероятность того, что удаленной машине не придется отображать никаких сообщений. Скорее всего, вам понадобится сервер, который только откроет подходящие каналы и зарегистрирует удаленные объекты для доступа клиента. Кроме того, при наличии простого консольного хоста вам (или кому-нибудь другому) придется вручную запустить компоновочный блок *.exe на стороне сервера, поскольку система удаленного взаимодействия .NET не предусматривает автоматический запуск файла *.exe на стороне сервера при вызове удаленным клиентом.

С учетом этих проблем возникает следующий вопрос: как создать невидимый приемник, который загрузится автоматически? Программисты .NET предлагают здесь на выбор две возможности.

• Построение .NET-приложения сервиса Windows, готового предложить хостинг для удаленных объектов.

• Разрешение осуществлять хостинг для удаленных объектов серверу IIS (Internet Information Server – информационный сервер Интернет).

Хостинг удаленных объектов с помощью сервиса Windows

Возможно, идеальным хостом для удаленных объектов является сервис Windows, поскольку сервис Windows позволяет следующее.

• Может загружаться автоматически при запуске системы

• Может запускаться, как "невидимый" процесс в фоновом режиме

• Может выполняться от имени конкретной учетной записи пользователя

Создать пользовательский сервис Windows средствами .NET исключительно просто, особенно в сравнении с возможностями непосредственного использования Win32 API. Для примера мы создадим проект Windows Service с именем CarWinService (рис. 18.7), который будет осуществлять хостинг удаленных типов, содержащихся в CarGeneralAsm.dll.

В результате Visual Studio 2005 сгенерирует парциальный класс (названный по умолчанию Service1), полученный из System.ServiceProcess.ServiceBase, и еще один класс (Program), реализующий метод Main() сервиса. Поскольку Service1 нельзя считать достаточно информативным именем для пользовательского сервиса, с помощью окна свойств укажите для свойств (Name) и ServiceName значение CarService. Различие между этими двумя свойствами в том, что значение (Name) задает имя, используемое для обращения к типу в программном коде, а свойство ServiceName обозначает имя, отображаемое в окне конфигурации сервисов Windows.

Перед тем как двигаться дальше, установите ссылки на компоновочные блоки CarGeneralAsm.dll и System.Remoting.dll, а также укажите следующие строки директив using в файле, содержащем определение класса CarService.

using System.Runtime.Remoting; 

using System.Runtime.Remoting.Channels.Http; 

using System.Runtime.Remoting.Channels; 

using System.Diagnostics;

Рис. 18.7. Создание рабочего пространства нового проекта Windows Service

Метод Main() класса Program обеспечивает запуск сервисов, определённых в проекте, путём передачи массива типов ServiceBase статическому методу Service.Run(). При условии, что имя пользовательского сервиса было изменено с Service1 на CarService, вы должны иметь следующее определение класса (для ясности программного кода здесь удалены комментарии).

static class Program {

 static void Main() {

  ServiceBase[] ServicesToRun;

  ServicesToRun = new ServiceBase[] { new CarService() };

 ServiceBase.Run(ServicesToRun);

 }

}

Вы, вероятно, уже догадываетесь, какая программная логика должна использоваться при запуске пользовательского сервиса. Напомним, что целью CarService является выполнение той задачи, которую выполнял ваш консольный сервис. Поэтому, чтобы зарегистрировать CarService в виде WKO-синглета, доступного по протоколу HTTP, можете добавить в метод OnStart() следующий программный код (при использовании сервисов Windows для обслуживания удаленных объектов вместо "жестко" запрограммированной реализации можно использовать тип RemotingConfiguration, позволяющий загрузить файл *.config удаленного взаимодействия на стороне сервера).

protected override void OnStart(string[] args) {

 // Создание нового HttpChannel.

 HttpChannel с = new HttpChannel(32469);

 ChannelServices.RegisterChannel(c);

 // Регистрация WKO-типа одиночного вызова.

 RemotingConfiguration.RegisterWellKnownServiceType(typeof(CarGeneralAsm.CarProvider), "CarProvider.soap", WellKnownObjectMode.SingleCall);

 // Сообщение об успешном старте.

 EventLog.WriteEntry("CarWinService", "CarWinService стартовал успешно!", EventLogEntryType.Information);

}

Заметим, что после регистрации типа в журнал регистрации событий Windows (с помощью типа System.Diagnostics.EventLog) записывается пользовательское сообщение с информацией о том, что машина-хост успешно запустила ваш сервис.

Строго говоря, CarService не требует никакой программной логики остановки. Но для примера давайте направим в EventLog еще одно событие, на этот раз с информацией о завершении работы пользовательского сервиса Windows.

protected override void OnStop() {

 EventLog.WriteEntry("CarWinService", "CarWinService остановлен", EventLogEntryType.Information);

}

Теперь, когда сервис полностью оформлен, следующей задачей является установка этого сервиса на удаленной машине.

Чтобы получить возможность установки сервиса на выбранной вами машине, нужно добавить в текущий проект CarWinService дополнительный тип. Для установки любого сервиса Windows (созданного как средствами .NET, так и средствами Win32 API) требуется создание в реестре целого ряда записей, которые позволят ОС взаимодействовать с сервисом. Вместо создания этих записей вручную, можно просто добавить в проект сервиса Windows тип Installer (установщик), который правильно сконфигурирует тип, производный от ServiceBase, для установки на целевой машине.

Чтобы добавить установщик для CarService, откройте окно проектирования сервиса (с помощью двойного щелчка на файле CarService.cs в окне Solution Explorer), щелкните правой кнопкой в любом месте окна проектирования сервиса и выберите Add Installer (добавить установщик), рис. 18.8.

Рис. 18.8. Добавление установщика для пользовательского сервиса Windows

В результате будет добавлен новый компонент, который оказывается производным базового класса System.Configuration.Install.Installer. В окне проектирования теперь будет два компонента. Тип serviceInstaller1 представляет установщик конкретного сервиса в вашем проекте. Выбрав соответствующую пиктограмму, вы обнаружите, что в окне Properties для свойства ServiceName установлено значение типа CarService.

Второй компонент (serviceProcessInstaller1) позволяет задать окружение, в котором будет выполняться установленный сервис. По умолчанию значением свойства Асcount (учетная запись) является User (пользователь). С помощью окна свойств Visual Studio 2005 измените это значение на LocalServicе (локальный сервис), рис. 18.9.

Рис. 18.9. Идентификация СarService

Вот и все! Теперь скомпилируйте свой проект.

Установка CarService.exe на машине (локальной или удаленной) предполагает выполнение двух действий.

1. Перемещение скомпилированного компоновочного блока сервиса (и всех необходимых внешних компоновочных блоков – в данном случае это CarGeneralAsm.dll) на удаленную машину.

2. Запуск средства командной строки installutil.exe с указанием соответствующего сервиса в качестве аргумента.

После выполнения п. 1 откройте командное окно Visual Studio 2005, перейдите в каталог с компоновочным блоком CarWinService.exe и введите следующую команду (этот же инструмент можно использовать и для деинсталляции сервиса).

installutil carwinservice.exe

После установки сервиса Windows вы можете запустить и сконфигурировать его с помощью апплета Services (Службы) Windows, который размещен в папке Администрирование панели управления Windows. В окне Services выделите CarService (рис. 18.10) и щелкните на ссылке Start (Запустить), чтобы загрузить и выполнить соответствующий двоичный файл.

Рис. 18.10. Апплет Services Windows

Исходный код. Проект CarWinService размещен в подкаталоге, соответствующем главе 18.

Хостинг удаленных объектов с помощью IIS

Хостинг удаленного компоновочного блока с помощью сервера IIS (Internet Information Server – информационный сервер Интернет) даже проще, чем создание сервиса Windows, поскольку сервер IIS специально запрограммирован на то, чтобы получать поступающие запросы HTTP через порт 80. Поскольку IIS является Web-сервером, должно быть очевидно, что IIS может осуществлять обслуживание только удаленных объектов, использующих тип HttpChannel (в отличие от сервиса Windows, который допускает также использование типа TcpChannel). С учетом этого ограничения, при использовании IIS для поддержки удаленного взаимодействия необходимо выполнить следующие действия.

1. На жестком диске создайте новую папку для хранения CarGeneralAsm.dll. В этой папке создайте подкаталог \Bin. Скопируйте файл CarGeneralAsm.dll в этот подкаталог (например, C:\IISCarService\Bin).

2. На машине-хосте откройте окно апплета Internet Information Services (размещенного в папке Администрирование панели управления Windows).

3. Щелкните правой кнопкой в строке узла Default Web Site (Web-узел по умолчанию) и выберите New→Virtual Directory из появившегося контекстного меню.

4. Создайте виртуальный каталог, соответствующий только что созданной вами корневой папке (C:\IISCarService). Остальные значения, предложенные мастером создания виртуального каталога, будут вполне подходящими.

5. Наконец, создайте новый файл конфигураций с именем web.config для настройки параметров регистрации удаленных типов виртуальным каталогом (см. следующий фрагмент программного кода). Сохраните этот файл в соответствующей корневой папке (в данном случае это папка C:\IISCarService).

‹configuration›

 ‹system.runtime.remoting›

 ‹application›

  ‹service›

    ‹wellknown mode="Singleton" type="CarGeneralAsm.CarProvider, CarGeneralAsm" objectUri="carprovider.soap" /›

  ‹/service›

  ‹channels›

   ‹channel ref="http"/›

  ‹/channels›

  ‹/application›

 ‹/system.runtime.remoting›

‹/configuration›

Теперь файл CarGeneralAsm.dll будет доступен для НТТР-запросов IIS, и вы можете обновить файл *.config на стороне клиента так, как показано ниже (конечно, указав в нем имя своего IIS-хоста).

‹configuration›

 ‹system.runtime.remoting›

 ‹application›

  ‹client displayName="CarClient"›

   ‹wellknown type="CarGeneralAsm.CarProvider, CarGeneralAsm" url="http://NameTheRemoteIISHost/IISCarHost/carprovider.soap"/›

   ‹/client›

  ‹channels›

   ‹channel ref="http"/›

   ‹/channels›

 ‹/application›

 ‹/sуstem.runtime.remoting› 

‹/configuration›

После этого вы сможете выполнять приложение клиента так же, как и раньше.

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

Для примера создайте новое консольное приложение (AsyncWKOCarProvider-Client) и установите в нем ссылку на первый вариант компоновочного блока CarGeneralAsm.dll. Теперь измените класс Program так, как показано ниже:

class Program {

 // Делегат для метода GetAllAutos().

 internal delegate List‹JamesBondCar› GetAllAutosDelegate();

 static void Main(string[] args) {

  Console.WriteLine("Старт клиента! Для завершения нажмите ‹Enter›");

 RemotingConfiguration.Configure("AsyncWKOCarProviderClient.exe.config");

  // Создание поставщика машин.

  CarProvider cp = new CarProvider();

 // Создание делегата.

  GetAllAutosDelegate getCarsDel = new GetAllAutosDelegate(cp.GetAllAutos);

  // Асинхронный вызов GetAllAutos().

  IAsyncResult ar = getCarsDel.BeginInvoke(null, null);

 // Имитация активности клиента.

  while (!ar.IsCompleted) { Console.WriteLine("Клиент работает…"); }

  // Все сделано! Получение возвращаемого значения делегата.

  List‹JamesBondCar allJBCs = getCarsDel.EndInvoke(ar);

  // Использование всех машин из списка.

  foreach(JamesBondCar j in allJBCs) UseCar(j);

 Console.ReadLine();

 }

}

Здесь приложение клиента сначала объявляет делегат, соответствующий сигнатуре метода GetAllAutos() удаленного типа CarProvider. После создания делегата имя вызываемого метода (GetAllAutos) передается ему, как обычно. Потом запускается метод BeginInvoke(), сохраняется результирующий интерфейс IAsyncResult и имитируется какая-то работа на стороне клиента (напомним, что свойство IAsyncResult.IsCompleted позволяет выяснить, завершил ли работу соответствующий метод). После завершения работы клиента вы получаете список List‹›, возвращенный методом CarProvider.GetAllAutos() в результате вызова члена EndInvoke(), и передаете каждый объект JamesBondCar статической вспомогательной функции с именем UseCar().

public static void UseCar(JamesBondCar j) {

 Console.WriteLine("Может ли машина летать"? {0}", j.isFlightWorthy);

 Console.WriteLine("Может ли машина плавать? {0}", j.isSeaWorthy);

}

Снова подчеркнем, что красота использования типа делегата .NET заключается в том, что форма асинхронного вызова удаленных методов оказывается аналогичной форме вызова локальных методов.

Исходный код. Проект AsynсWKOCarProviderClient размещен в подкаталоге, соответствующем главе 18.

Роль атрибута [OneWay]

Предположим, что CarProvider должен иметь метод AddCar(), принимающий в качестве входного параметра JamesBondCar и не возвращающий ничего. Здесь главное те, что метод не возвращает ничего. Из названия класса System.Runtime. Remoting.Messaging.OneWayAttribute можно догадаться, что в данном случае слой удаленного взаимодействия .NET передает вызов удаленной стороне односторонним способом, и не заботится о создании инфраструктуры, необходимой для возврата значения (отсюда и название one-way - односторонний). Вот соответствующая модификация класса.

// "Обитель" атрибута [OneWay].

using System.Runtime.Remoting.Messaging;

…

namespace CarGeneralAsm {

 public class CarProvider: MarshalByRefObject {

  …

  // Клиент может вызвать соответствующий метод

 // и 'забыть' о нем.

  [OneWay]

  public void AddCar(JamesBondCar newJBC) { theJBCars.Add(newJBC); }

 }

}

Вызывающая сторона вызывает этот метод так, как обычно.

// Создание поставщика машин.

CarProvider ср = new CarProvider(); 

// Добавление новой машины.

ср.AddCar(new JamesBondCar("Zippy", 200, false, false));

С точки зрения клиента вызов AddCar() является полностью асинхронным, поскольку среда CLR обеспечивает использование фонового потока для запуска удаленного метода. Поскольку AddCar() сопровождается атрибутом [OneWay], клиент не может получить от вызова никакого возвращаемого значения. Но, поскольку AddCar() возвращает void, это не является проблемой.

Вдобавок к указанному ограничению, следует также знать о том, что при наличии у метода с атрибутом [OneWay] выходных или ссылочных параметров (определяемых с помощью ключевых слов out или ref) вызывающая сторона не сможет получить модификации вызываемой стороны. К тому же, если вдруг метод с атрибутом [OneWay] сгенерирует исключительное состояние (любого типа), вызывающая сторона ничего об этом не узнает. Удаленные объекты могут обозначить некоторые методы атрибутом [OneWay] только тогда, когда вызывающей стороне действительно позволяется вызвать эти методы и "забыть" об этом.

При построении приложения Windows Forms вы можете, при желании, создать весь соответствующий программный код вручную (например, в редакторе Блокнот или в редакторе TextPad), а затем отправить файлы *.cs компилятору командной строки C# с флагом /target:winexe. Построение нескольких приложений Windows Forms вручную дает не только бесценный опыт, но и помогает лучше понять программный код, генерируемый графическими средствами проектирования, предлагаемыми в рамках пакетов интегрированной среды разработки .NET разных производителей.

Чтобы вы могли понять основы процесса создания приложений Windows Forms, в первых примерах этой главы не используются графические средства проектирования. Освоив процесс построений приложений Windows Forms "без помощи мастеров", вы без труда сможете перейти к использованию различных инструментов разработки, встроенных в Visual Studio 2005.

Создание главного окна вручную

В начале изучения приемов программирования Windows Forms мы построим самое простое главное окно, так сказать, "с чистого листа". Создайте на своем жест-ком диске новую папку (например, C:\MyFirstWindow) и в этой папке с помощью любого текстового редактора создайте новый файл MainWindow.cs.

В Windows Forms класс Form используется для представления любого окна в приложении. Это относится и к главному окну, находящемуся на вершине иерархии окон в приложении с интерфейсом SDI (Single-Document Interface – однодокументный интерфейс), и к модальным и немодальным диалоговым окнам, и к родительским и дочерним окнам в приложении с интерфейсом MDI (Multiple Document Interface – многодокументный интерфейс). Чтобы создать и отобразить главное окно приложения, необходимо выполнить следующие два обязательных шага.

1. Получить новый класс из System.Windows.Forms.Form.

2. Добавить в метод Main() приложения вызов метода Application.Run(), передав этому методу экземпляр производного от Form типа в виде аргумента.

Поэтому добавьте в файл MainWindow.cs следующее определение класса.

using System;

using System.Windows.Forms;

namespace MyWindowsApp {

 public class MainWindow : Form {

  // Выполнение приложения и идентификация главного окна.

  static void Main(string[] args) {

  Application.Run(new MainWindow());

  }

 }

}

Вдобавок к обязательно присутствующему модулю mscorlib.dll, приложение Windows Forms должно сослаться на компоновочные блоки System.dll и System.Windows.Forms.dll. Вы, может быть, помните из главы 2, что используемый по умолчанию ответный файл C# (файл csc.rsp) дает указание csc.exe автоматически включить эти компоновочные блоки в процесс компиляции, так что здесь никаких проблем не ожидается. Также напомним, что опция /target:winexe компилятора csc.exe означает создание выполняемого файла Windows.

Замечание. Строго говоря, можно построить приложение Windows и с помощью опции /target:exe компилятора csc.exe, но тогда кроме главного окна полученное приложение в фоновом режиме будет создавать командное окно (которое будет существовать до тех пор, пока не завершит работу главное окно приложения). Указав /target:winexe, вы получите приложение, выполняемое в так называемом "родном" для Windows Forms режиме (без создания фонового командного окна).

Чтобы скомпилировать файл программного кода C#, откройте окно командной строки Visual Studio 2005 и выберите следующую команду.

csc /target:winexe *.cs

На рис. 19.1 показан результат запуска полученного приложения.

Рис. 19.1. Главное окно в стиле Windows Forms

Понятно, что такой результат применения средств Windows Forms впечатления не производит. Но обратите внимание на то, что путем получения простой производной от Form мы создали главное окно, допускающее минимизацию, максимизацию, изменение размеров и закрытие (да еще и с пиктограммой, предлагаемой системой по умолчанию!). В отличие от других средств разработки графического интерфейса от Microsoft, которые вы, возможно, использовали ранее (в частности, это касается библиотеки базовых классов MFC), теперь нет необходимости связывать сотни строк программного кода соответствующей инфраструктуры (фреймов, документов, представлений, приложений и карт сообщений). В отличие от приложений Win32 API, использующих C, здесь нет необходимости вручную реализовывать процедуры WinProc() и WinMain(). В рамках платформы .NET эту "грязную" работу выполняют элементы, инкапсулированные в типах Form и Application.

Принцип разграничения обязанностей

Сейчас класс MainWindow определяет метод Main() в рамках своего контекста. Но, если хотите, можно создать другой статический класс (назовем его Program). который будет отвечать за запуск главного окна, а задачей класса, производного от Form, останется непосредственное отображение окна.

namespace MyWindowsApp {

 // Главное окно.

 public class MainWindow: Form {}

 // Объект приложения.

 public static class Program {

  static void Main(string[] args) {

  // He забудьте о 'using' для System.Windows.Forms! 

  Application.Run(new MainWindow());

  }

 }

}

В результате вы обеспечите поддержку одного из главных правил объектно-ориентированного программирования – разграничение обязанностей. Это правило требует, чтобы класс был ответственен за выполнение минимально возможного объема работы. Разделив исходный класс на два отдельных класса, вы тем самым отделили форму от создающего ее класса. Результатом оказывается более мобильное (в смысле переносимости) окно, поскольку его теперь можно поместить в рамки любого проекта без дополнительного метода Main(), специфичного для данного проекта.

Исходный код. Проект MyFirstWindow размещён в подкаталоге, соответствующем главе 19.

Класс Application определяет множество статических членов, позволяющих управлять поведением различных низкоуровневых элементов приложения Windows Forms. Класс Application определяет набор событий, позволяющих реагировать, например, на завершение работы приложения или переход в состояние ожидания.

Кроме метода Run(), этот класс предлагает и другие методы, о которых вам следует знать.

• DoEvents(). Обеспечивает для приложения возможность в ходе выполнения операций, требующих много времени, обрабатывать сообщения, находящихся в это время в очереди сообщений.

• Exit(). Завершает выполнение Windows-приложения и выгружает из памяти домен этого приложения.

• EnableVisualStyles(). Настраивает приложение на поддержку визуальных стилей Windows XP. При активизации поддержки ХР-стилей указанный метод должен вызываться до загрузки главного окна с помощью Application.Run().

Кроме того, класс Application определяет ряд свойств, многие из которых доступны только для чтения. При анализе табл. 19.2 обратите внимание на то, что большинство свойств представляет характеристики "уровня приложения" (имя компании, номер версии и т.д.). С учетом ваших знаний об атрибутах уровня компоновочного блока (см. главу 12) многие из этих свойств должны быть для вас понятны.

Таблица 19.2. Основные свойства типа Application

Наконец, класс Application определяет набор статических событий, и вот некоторые из них.

• ApplicationExit генерируется непосредственно перед тем, как данное приложение завершает работу.

• Idle генерируется тогда, когда цикл сообщений приложения заканчивает обработку текущего пакета сообщений и готовится к переходу в состояние ожидания (ввиду отсутствия сообщений для обработки).

• ThreadExit генерируется непосредственно перед тем, как завершает работу поток данного приложения.

Возможности класса Application

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

• Использовать значения некоторых атрибутов уровня компоновочного блока.

• Обрабатывать статическое событие ApplicationExit…

Первой нашей задачей является использование свойств класса Application для отображения атрибутов уровня компоновочного блока. Для начала добавьте в свой файл MainWindow.cs следующие атрибуты (обратите внимание на то, что здесь используется пространство имен System.Reflection).

using System;

using System.Windows.Forms;

using System.Reflection;

// Несколько атрибутов для данного компоновочного блока.

[аssembly:AssemblyCompany("Intertech Training")] [assembly: AssemblyProduct("Более совершенное окно")"] [assembly:AssemblyVersion("1.1.0.0")]

namespace MyWindowsApp {

 …

}

Вместо того чтобы отображать атрибуты [AssemblyCompany] и [AssemblyProduct] вручную, используя приемы, предлагавшиеся в главе 12, класс Application позволяет сделать это автоматически, используя различные статические свойства. Например, можно реализовать конструктор следующего вида, который будет играть роль конструктора, заданного по умолчанию.

public class MainWindow: Form {

 publiс MainWindow() {

  MessageBox.Show(Application.ProductName, String.Format("Это приложение создано для вас компанией {0}", Application.CompanyName));

 }

}

Выполнив это приложение, вы увидите окно сообщения, отображающее соответствующую информацию (рис. 19.2).

Рис 19.2. Чтение атрибутов с помощью типа Application

Теперь позволим форме отвечать на событие ApplicationExit. Вам, наверное, будет приятно узнать, что для обработки событий в рамках графического интерфейса приложений Windows Forms используется синтаксис событий, уже подробно описанный выше в главе 8. Поэтому, чтобы выполнить перехват статического события ApplicationExit, просто зарегистрируйте обработчик события с помощью операции +=.

public class MainForm: Form {

 public MainForm() {

  // Перехват события ApplicationExit.

  Application.ApplicationExit += new EventHandler(MainWindow_OnExit);

 }

 private void MainWindow_OnExit(object sender, EventArgs evArgs) {

  MessageBox.Show(string.Format("Форма версии {0} завершила работу.", Application.ProductVersion));

 }

}

Делегат System.EventHandler

Обратите внимание на то, что событие ApplicationExit работает в паре с делегатом System.EventHandler. Этот делегат может указывать методы, соответствующие следующей сигнатуре.

delegate void EventHandler(object sender, EventArgs e);

Делегат System.EventHandler является самым примитивным делегатом, используемым для обработки событий Windows Forms, но существует очень много его вариаций. Что же касается EventHandler, то его первый параметр (типа System. Object) представляет объект, сгенерировавший данное событие. Второй параметр EventArgs (или его потомок) может содержать любую информацию, относящуюся к данному событию.

Замечание. Класс EventArgs является базовым для множества производных типов, содержащих дополнительную информацию для событий из определенных семейств. Так, для событий мыши используется параметр MouseEventArgs, предлагающий, например, такую информацию, как позиция (х, у) указателя. Для событий клавиатуры используется тип KeyEventArgs, предоставляющий информацию о текущих нажатиях клавиш и т.д.

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

Исходный код. Проект AppClassExample размещен в подкаталоге, соответствующем главе 19.

Класс System.Windows.Forms.Control задает общее поведение, ожидаемое от любого GUI-типа. Базовые члены Control позволяют указать размер и позицию элемента управления, выполнить захват событий клавиатуры и мыши, получить и установить фокус ввода, задать и изменить видимость членов и т.д. В табл. 19.4 определяются некоторые (но, конечно же, не все) свойства, сгруппированные по функциональности.

Таблица 19.4. Базовые свойства типа Control

Кроме того, класс Control определяет ряд событий, позволяющих реагировать на изменение состояния мыши, клавиатуры, действия выделения и перетаскивания объектов (а также на многие другие действия). В табл. 19.5 предлагается описок некоторых (но далеко не всех) событий, сгруппированных по функциональности.

Таблица 19.5. События типа Control

Наконец, базовый класс Control определяет целый ряд методов, позволяющих взаимодействовать с любым типом, производным от Control. При ближайшем рассмотрений методов Control вы обнаружите, что многие из них имеют префикс On, за которым следует имя соответствующего события (OnMouseMove, OnKeyUp, OnPaint и т.д.). Каждый из этих снабженных префиксом виртуальных методов представляет собой обработчик соответствующего события, заданный по умолчанию. Переопределив такой виртуальный член, вы получаете возможность выполнить необходимую предварительную (или заключительную) обработку данных, перед вызовом (или после вызова) родительской реализации обработчика события.

public class MainWindow: Form {

 protected override void OnMouseDown(MouseEventArgs e) {

  // Добавленный программный код для события MouseDown.

  // Вызов родительской реализации.

  base.OnMouseDown(e);

 }

}

Это может оказаться полезным, например, при создании пользовательских элементов управления, которые получаются из стандартных (см. главу 21), но чаще всего вы будете использовать обработку событий в рамках стандартного синтаксиса событий C# (именно это предлагается средствами проектирования Visual Studio 2005 по умолчанию). В этом случае среда разработки вызовет пользовательский обработчик события после завершения работы родительской реализации.

public class MainWindow: Form {

 public MainWindow() {

  MouseDown += new MouseEventHandler(MainWindow_MouseDown);

 }

 void MainWindow_MouseDown(object sender, MouseEventArgs e) {

  // Добавленный программный код для события MouseDown.

 }

}

Кроме методов вида OnХХХ(), есть несколько других методов, о которые вам следует знать.

• Hide(). Скрывает элемент управления, устанавливая для его свойства Visible значение false (ложь).

• Show(). Делает элемент управления видимым, устанавливая для его свойства Visible значение true (истина).

• Invalidate(). Заставляет элемент управления обновить свое изображение, посылая событие Paint.

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

Использование возможностей класса Control

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

• Отвечать на события MouseMove и MouseDown.

• Выполнять захват и обработку ввода с клавиатуры, реагируя на событие KeyUp.

Для начала создайте новый класс, производный от Form. В конструкторе, заданном по умолчанию, мы используем различные наследуемые свойства, чтобы задать исходный вид и поведение формы. Обратите внимание на то, что здесь нужно указать использование пространства имён System.Drawing поскольку необходимо получить доступ к структуре Color (пространство имен System.Drawing будет рассмотрено в следующей главе).

using System;

using System.Windows.Forms;

using System.Drawing;

namespace MyWindowsApp {

 public class MainWindow: Form {

 publiс MainWindow() {

   // Использование наследуемых свойств для установки

  // характеристик интерфейса пользователя.

Text = "Моя фантастическая форма";

   Height = 300;

  Width = 500;

  BackColor = Color.LemonChiffon;

   Cursor = Cursors.Hand;

 }

 }

 public static class Program {

  static void Main(string[] args) {

   Application.Run(new MainWindow());

 }

 }

}

Скомпилируйте это приложение в его текущем виде, просто чтобы проверить что вы не допустили никаких опечаток.

csc /target:winexe *.cs

Ответ на события MouseMove

Далее, мы должны обработать событие MouseMove. Целью является отображение текущих координат (x, у) указателя в области заголовка формы. Все связанные с состоянием мыши события (MouseMove. MouseUp и т.д.) работают в паре с делегатом MouseEventHandler, способным вызвать любой метод, соответствующий следующей сигнатуре.

void MyMouseHandler(object sender, MouseEventArgs e);

Поступающая на вход структура MouseEventArgs расширяет общий базовый класс EventArgs путем добавления целого ряда членов, специально предназначенных для обработки действий мыши (табл. 19.6).

Таблица 19.6. Свойства типа MouseEventArgs

Вот обновленный класс MainForm, в котором обработка события MouseMove происходит так, как предполагается выше.

public class MainForm: Form {

 public MainForm() {

  …

  // Для обработки события MouseMove.

  MouseMove += new MouseEventHandler(MainForm_MouseMove);

 }

 // Обработчик события MouseMove.

 public void MainForm_MouseMove(object sender, MouseEventArgs e) {

  Text = string. Format ("Текущая позиция указателя: ({0}, {1})", е.Х, e.Y);

 }

}

Если теперь запустить программу и поместить указатель мыши на форму, вы увидите текущие значения координат (х, у) указателя, отображенные в области заголовка соответствующего окна (рис. 19.4).

Рис. 19.4. Мониторинг движения мыши

Регистрация щелчков кнопок мыши

Следует подчеркнуть, что событие MouseUp (как и MouseDown) посылается при щелчке любой кнопки мыши. Если нужно выяснить, какой кнопкой мыши был выполнен щелчок (левой, правой или средней), следует проанализировать значение свойства Button класса MouseEventArgs. Значение свойства Button соответствует одному из значений перечня MouseButtons. Предположим, что для обработки со-бытия MouseUp вы изменили заданный по умолчанию конструктор так, как показано ниже.

public MainWindow() {

 …

 // Для обработки события MouseUp.

 MouseUp += new MouseHandler(MainForm_MouseUp);

}

Следующий обработчик события MouseUp сообщает в окне сообщения о том, какой кнопкой мыши был выполнен щелчок.

public void MainForm_MouseUp(object sender, MouseEventArgs e) {

 // Какая кнопка мыши была нажата?

 if (e.Button == MouseButtons.Left) MessageBox.Show("Щелчок левой кнопки"); 

 if (e.Button == MouseButtons.Right) MessageBox.Show("Щелчок правой кнопки"); 

 if (e.Button == MouseButtons.Middle) MessageBox.Show("Щелчок средней кнопки");

}

Ответ на события клавиатуры

Обработка ввода с клавиатуры почти идентична обработке событий мыши. cобытия KeyUp и KeyDown работают в паре с делегатом KeyEventHandler, который может указывать на любой метод, получающий объект общего вида в качестве первого параметра, и KeyEventArgs – в качестве второго.

void MyKeyboardHandler(object sender, KeyEventArgs e); 

Описания членов KeyEventArgs предлагаются в табл. 19.7.

Таблица 19.7. Свойства типа KeyEventArgs

Измените объект MainForm, чтобы реализовать обработку события KeyUp. В окне сообщения отобразите название нажатой клавиши, используя свойство KeyCode.

public class MainForm: Form {

 public MainForm() {

  …

  // Для отслеживания событий KeyUp.

  KeyUp += new KeyEventHandler(MainForm_KeyUp);

 }

 private void MainForm_KeyUp (object sender, KeyEventArgs e) {

  MessageBox.Show(e.KeyCode.ToString(), "Нажата клавиша!");

 }

}

Скомпилируйте и запустите программу. Теперь вы должны иметь возможность не только определить, какой кнопкой мыши был выполнен щелчок, но и то, какая была нажата клавиша на клавиатуре.

На этом мы завершим обсуждение функциональных возможностей базового класса Control и перейдем к обсуждению роли Form.

Исходный код. Проект ControlBehaviors размещен в подкаталоге, соответствующем главе 19.

Класс Form обычно (но не обязательно) является непосредственным базовым классом для пользовательских типов Form. В дополнение к большому набору членов, унаследованных от классов Control, ScrollableControl и ContainerControl, тип Form предлагает свои собственные функциональные возможности, в частности для главных окон, дочерних окон MDI и диалоговых окон. Давайте сначала рассмотрим базовые свойства, представленные в табл. 19.8.

Таблица 19.8. Свойства типа Form

В дополнение к ожидаемым обработчикам событий с префиксом On, предлагаемым по умолчанию, в табл. 19.9 предлагается список некоторых базовых методов, определенных типом Form.

Таблица 19.9. Основные методы типа Form

Наконец, класс Form определяет ряд событий, связанных с циклом существования формы. Основные такие события описаны в табл. 19.10.

Таблица 19.10. Подборка событий типа Form

Цикл существования типа Form

Если вы имеете опыт программирования интерфейсов пользователя с помощью таких пакетов разработки, как Java Swing, Mac OS X Cocoa или Win32 АРI, вы должны знать, что "оконные типы" поддерживают множество событий, происходящих в различные моменты цикла существования таких типов. То же самое можно сказать и о типах Windows Forms. Вы уже видели, что "жизнь" формы начинается тогда, когда вызывается конструктор типа, перед его передачей методу Application.Run().

После размещения соответствующего объекта в управляемой динамической памяти среда разработки приложений генерирует событие Load. В обработчике событий Load можно настроить вид и поведение формы, подготовить содержащиеся в форме дочерние элементы управления (окна списков, деревья просмотра и т.д.), организовать доступ к ресурсам, необходимым для работы формы (установить связь с базами данных, создать агенты для удаленных объектов и т.д.).

Следующим событием, генерируемым после события Load, является событие Activated. Это событие генерируется тогда, когда форма получает фокус ввода, как активное окно на рабочем столе. Логическим "антиподом" события Activated является (конечно же) событие Deactivate, которое генерируется тогда, когда форма утрачивает фокус ввода, становясь неактивным окном. Легко догадаться, что события Activated и Deactivate в цикле существования формы могут генерироваться множество раз, поскольку пользователь может переходить от одного активного приложения к другому.

Когда пользователь решает закрыть соответствующую форму, по очереди генерируются еще два события: Closing и Closed. Событие Closing генерируется первым и дает возможность предложить конечному пользователю многими нелюбимое (но полезное) сообщение "Вы уверены, что хотите закрыть это приложение?". Этот шаг с требованием подтвердить выход полезен тем. что пользователю получает возможность сохранить данные соответствующего приложения перед завершением работы программы.

Событие Closing работает в паре с делегатом CancelEventHandler, определенным в пространстве имен System.ComponentModel. Если установить для свойства CancelEventArgs.Cancel значение true (истина), форме будет дано указание возвратиться к нормальной работе, и форма уничтожена не будет. Если установить для CancelEventArgs.Cancel значение false (ложь), будет сгенерировано событие Closed, и приложение Windows Forms будет завершено (домен приложения будет выгружен и соответствующий процесс прекращен).

Чтобы закрепить в памяти последовательность событий, происходящих в рамках цикла существовании формы, рассмотрим новый файл MainWindow.cs, в котором события Load, Activated, Deactivate, Closing и Closed обрабатываются в конструкторе класса так, как показано ниже (не забудьте добавить в программу директиву using для пространства имен System.ComponentModel, чтобы получить доступ к определению CancelEventArgs).

public MainForm() {

 // Обработка различных событий цикла существования формы.

 Closing += new CancelEventHandler(MainForm_Closing);

 Load += new EventHandler(MainForm_Load);

 Closed += new EventHandler(MainForm_Closed);

 Activated += new EventHandler(MainForm_Activated);

 Deactivate += new EventHandler(MainForm_Deactivate);

}

В обработчиках событий Load, Closed, Activated и Deactivate в строковую переменную System.String (с именем LifeTimeInfo) добавляется имя перехваченного события. Обработчик события Closed отображает значение этой строки в окне сообщения.

private void MainForm_Load(object sender, System.EventArgs e) { lifeTimeInfo += "Событие Load\n"; }

private void MainForm_Activated(object sender, System.EventArgs e) { lifeTimeInfo += "Событие Activate\n"; }

private void MainForm_Deactivate(object sender, System.EventArgs e) { lifeTimeInfo += "Событие Deactivate\n"; }

private void MainForm_Closed(object sender, System.EventArgs e) {

 lifeTimeInfo += "'Событие Closed\n";

 MessageBox.Show(lifeTimeInfо);

}

В обработчик события Closing задается вопрос о том, действительно ли пользователь желает завершить работу приложения. При этом используется поступающий на вход объект CancelEventArgs.

private void MainForm_Closing(object sender, CancelEventArgs e) {

 DialogResult dr = MessageBox.Show("Вы ДЕЙСТВИТЕЛЬНО хотите закрыть приложение?", "Событие Closing", MessageBoxButtons.YesNo);

 if (dr == DialogResult.No) e.Cancel = true;

 else e.Cancel = false;

}

Обратите внимание на то, что метод MessageBox.Show() возвращает тип DialogResult, значение которого идентифицирует кнопку (Да, Нет), нажатую в форме конечным пользователем. Теперь скомпилируйте полученный программный код в командной строке.

csc /target:winexe *.cs

Запустите приложение на выполнение и несколько раз поочередно предоставьте форме фокус ввода и уберите ее из фокуса ввода (чтобы сгенерировать события Activated и Deactivate). После прекращения работы вы увидите блок сообщений, аналогичный показанному на рис. 19.5.

Рис. 19.5. "Биография" типа, производного от Form

Большинство наиболее интересных возможностей типа Form связано с созданием и настройкой систем меню, панелей инструментов и строк состояния. Необходимый для этого программный код не слишком сложен, но Visual Studio 2005 предлагает целый набор графических инструментов проектирования, которые позаботятся о создании значительной части такого программного кода за вас. Поэтому давайте на время скажем "до свидания" компилятору командной строки и займемся созданием приложений Windows Forms с помощью Visual Studio 2005.

Исходный код. Проект FormLifeTime размещен в подкаталоге, соответствующем главе 19.

В Visual Studio 2005 предлагается специальный шаблон для создания приложений Windows Forms. Выбрав шаблон Windows Application при создании проекта, вы получите не только объект приложения с соответствующим методом Main(), но и подходящий исходный тип, производный от Form. Кроме того, среда разработки предложит вам целый набор графических инструментов проектирования, способных превратить процесс построения интерфейса пользователя в детскую забаву. Чтобы рассмотреть имеющиеся возможности, создайте рабочее пространство нового проекта Windows Application (рис. 19.6). Мы пока что не собираемся создавать рабочий пример, так что можете назвать этот проект так, как захотите.

Рис. 19.6. Проект Windows Application в Visual Studio 2005

После загрузки проекта вы увидите окно проектирования формы, которое позволяет строить пользовательский интерфейс путем перетаскивания элементов управления и компонентов из панели инструментов (окно Toolbox, рис. 19.7), а также настраивать свойства и события этих элементов управления и компонентов с помощью окна свойств (окно Properties, рис. 19.8).

Рис. 19.7. Панель инструментов Visual Studio 2005

Рис. 19.8. Окно свойств Visual Studio 2005

Как видите, элементы управления в панели инструментов сгруппированы по категориям. В большинстве своем эти категории самоочевидны – например, категория Printing (Печать) содержит средства управления печатью. Menus & Toolbars (Меню и панели инструментов) содержит рекомендуемые элементы управления для меню и панелей инструментов и т.д. Тем не менее, пара категорий заслуживает специального обсуждения.

• Common Controls (Общие элементы управления). Элементы этой категории можно считать "рекомендуемым набором" общих элементов управления для построения пользовательского интерфейса.

• All Windows Forms (Все элементы управления Windows Forms). Здесь вы найдете полный набор элементов управления Windows Forms, включая элементы управления .NET 1.х, которые считаются устаревшими.

Второй из указанных здесь пунктов заслуживает более пристального внимания. Если вы работали с Windows Forms в рамках .NET 1.x, вам будет полезно знать, что многие привычные для вас элементы управления (например, элемент управления DataGrid) находятся как раз под "знаком" категории All Windows Forms. К тому же, некоторые общие элементы управления, которые вы могли использовать в рамках .NET 1.x (например, MainMenu, ToolBar и Statusbar) по умолчанию в панели Toolbox не показаны.

Получение доступа к устаревшим элементам управления

Во-первых, отметим, что устаревшие элементы пользовательского интерфейса, о которых здесь идет речь, остаются пригодными для использования в .NET 2.0, а во-вторых, если вы хотите их использовать, то их можно снова добавить в панель инструментов. Для этого щелкните правой кнопкой мыши в любом месте окна Toolbox (кроме строки заголовка) и выберите Choose Items (Выбрать элементы) из появившегося контекстного меню. В появившемся диалоговом после этого окне отметьте нужные вам элементы (рис. 19.9).

Рис. 19.9. Добавление элементов управления на панель инструментов

Замечание. Может показаться, что а списке в окне добавления элементов управления имеются повторения (например, для элемента управления ToolBar). На самом же деле каждый элемент списка уникален, так как соответствующий элемент управления может иметь другую версию (например, 2.0 вместо 1.0) и/или быть элементом .NET Compact Framework. Поэтому будьте внимательны, чтобы выбрать правильный элемент.

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

Замечание. В этой главе мы используем новое, рекомендуемое сегодня множество элементов управления пользовательского интерфейса. Чтобы получить информацию, необходимую для работы с устаревшими типами MainMenu, Statusbar и другими аналогичными им типами, обратитесь к документации .NET Framework 2.0 SDK.

Анализ проекта Windows Forms в Visual Studio 2005

Любой тип Form проекта Windows Forms в Visual Studio 2005 представлен двумя связанными C#-файлами, в чем можно убедиться непосредственно, заглянув в окно Solution Explorer (рис. 19.10).