• Главная
• Контакты
• Нашёл ошибку
• Прислать материал
• Добавить в избранное

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

В .NET пространство имен System.IO является той частью библиотек базовых адресов, которая обслуживает службы ввода-вывода, как для файлов, так и для памяти. Подобно любому другому пространству имен, System.IO определяет свой набор классов, интерфейсов, перечней, структур и делегатов, большинство из которых содержится в mscorlib.dll. Вдобавок к типам, содержащимся в mscorlib.dll, часть членов System.IO содержится в компоновочном блоке System.dll (все проекты в Visual Studio 2005 автоматически устанавливают ссылку на оба эти компоновочных блока, поэтому вам об этом беспокоиться не приходится).

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

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

Таблица 16.1. Ключевые типы пространства имен System.IO

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

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

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

Типы 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

Свойство 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. Сначала используем метод 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.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);

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

Чтобы проиллюстрировать некоторые функциональные возможности типа Directory, заключительная модификация этого примера отображает имена всех дисков, отображаемых на данном компьютере (для этого применяется метод Directorу.GetLogicalDrives()) и используется статический метод Directory. Delete() для удаления ранее созданных подкаталогов \MyFoo и \MyBar\MyQaaz.

class Program {

 static void Main(string[] args) {

  …

  // Список дисков данного компьютера.

  string[] drives = Directory.GetLogicalDrives();

  Console.WriteLine("Вот ваши диски:");

  foreach (string s in drives) Console.WriteLine(" -› {0}", s);

  // Удаление созданного.

  Console.WriteLine("Нажмите ‹Enter› для удаления каталогов");

  try {

   // Второй параметр сообщает, хотите ли вы

   // уничтожить подкаталоги

   Directory.Delete(@"C:\Windows\MyBar", true);

  } catch (IOException e) {

   Console.WriteLine(e.Message);

  }

 }

}

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

В .NET 2.0 пространство имен System.IO предлагает класс с именем DriveInfo. Подобно Directory.GetLogicalDrives(), статический метод DriveInfo.GetDrives() позволяет выяснить имена дисков машины. Однако, в отличие от Directory.GetLogicalDrives(), класс DriveInfo обеспечивает множество дополнительной информации (например, информацию о типе диска, свободном пространстве, метке тома и т.д.). Рассмотрите следующий пример программного кода.

class Program {

 static void Main(string[] args) {

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

  // Получение информации о дисках.

  // Вывод информации о состоянии.

  foreach(DriveInfo d in myDrives) {

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

   Console.WriteLine("Тип: {0}", d.DriveType);

   // Проверка диска.

   if (d.IsReady) {

    Console.WriteLine("Свободно: {0}", d.TotalFreeSpace);

    Console.WriteLine("Формат: {0}", d.DriveFormat);

    Console.WriteLine("Метка тома: {0}\n", d.VolumeLabel);

   }

  }

  Console.ReadLine();

 }

}

На рис. 16.5 показан вывод, соответствующий состоянию моей машины.

Рис. 16.5. Сбор информации о дисках с помощью DriveInfo

Итак, мы рассмотрели некоторые возможности классов Directory.DirectoryInfo и DriveInfo. Далее вы узнаете, как создавать, открывать, закрывать и уничтожать файлы, присутствующие в каталоге.

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

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

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

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

Первая возможность создания дескриптора файла обеспечивается методом 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(), обеспечивает полный доступ чтения/записи всем пользователям.

Метод 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.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(). В отличие от 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 обеспечивает возможность чтения символьных данных из соответствующего файла.

И последними интересующими нас на этот момент методами будут 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();

}

В отличие от 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 обеспечивает реализацию абстрактных членов 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, выведенные на консоль.

Одной из смущающих особенностей работы с типами из 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.

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

static void Main(string[] args) {

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

 // Создание StringWriter и вывод символьных данных в память.

 StringWriter strWriter = new StringWriter();

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

 strWriter.Close();

 // Получение копии содержимого (сохраненного в строке) и

 // вывод на консоль.

 Console.WriteLine("Содержимое StringWriter:\n{0}", strWriter);

}

Ввиду того, что и StringWriter, и StreamWriter получаются из одного и того же базового класса (TextWriter), для них используется приблизительно одинаковая программная логика записи. Однако ввиду самой своей природы, класс StringWriter позволяет извлечь объект System.Text.StringBuilder с помощью метода GetStringBuilder().

static void Main(string[] args) {

 Соnsоlе.WriteLine("*** Забавы с StringWriter/StringReader ***\n'');

 …

 // Создание StringWriter и вывод символьных данных в память.

 StringWriter strWriter = new StringWriter();

 …

 // Получение внутреннего StringBuilder.

 StringBuilder sb = strWriter.GetStringBuilder();

 sb.Insert(0, "Эй!! ");

 Console.WriteLine("-› {0}", sb.ToString());

 sb.Remove(0, "Эй!! ".Length);

 Console.WriteLine("-› {0}", sb.ToString());

}

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

static void Main(string[] args) {

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

 // Создание StringWriter и вывод символьных данных в память.

 StringWriter strWriter = new StringWriter();

 …

 // Чтение данных из StringWriter.

 StringReader strReader = new StringReader(writer.ToString());

 string input = null;

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

  Console.WriteLine(input);

 }

 strReader.Close();

}

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

И последним из рассмотренных здесь средств чтения/записи будут BinaryReader и BinaryWriter, которые получаются непосредственно из System.Object. Эти типы позволяют читать и записывать дискретные типы данных в соответствующий поток в компактном двоичном формате. Класс BinaryWriter определяет чрезвычайно перегруженный метод Write(), позволяющий поместить тип данных в соответствующий поток. Вдобавок к Write(), класс BinaryWriter предлагает дополнительные члены, позволяющие получить или установить тип, производный от Stream, и обеспечить поддержку прямого доступа к данным (табл. 16.9).

Таблица 16.9. Основные члены BinaryWriter 

Класс BinaryReader дополняет функциональные возможности, предлагаемые членами BinaryWriter (табл. 16.10).

Таблица 16.10. Основные Члены BinaryReader

В следующем примере в новый файл *.dat записывается целый ряд типов данных,

static void Main(string[] args) {

 // Открытие сеанса двоичной записи в файл.

 FileInfo f = new FileInfo("BinFile.dat");

 BinaryWriter bw = new BinaryWriter(f.OpenWrite());

 // Печать информации о типе BaseStream.

 // (в данном случае это System.IO.FileStream) .

 Console.WriteLine("Базовый поток: {0}", bv.BaseStream);

 // Создание порции данных для сохранения в файле.

 double aDouble = 1234.67;

 int anInt = 34567;

 char[] aCharArray = { 'A', 'В', 'С'};

 // Запись данных.

 bw.Write(aDouble);

 bw.Write(anInt);

 bw.Write(aCharArray);

 bw.Close();

}

Обратите внимание на то, что объект FileStream, возвращенный из FileInfo.OpenWrite(), передается конструктору типа BinaryWriter. С помощью такого подхода очень просто выполнить "расслоение" потока перед записью данных. Следует осознавать, что конструктор BinaryWriter способен принять любой тип, производный от Stream (например, FileStream, MemoryStream или BufferedStream). Поэтому, если нужно записать двоичные данные, например, в память, просто укажите подходящий объект MemoryStream.

Для чтения данных из файла BinFile.dat тип BinaryReader предлагает множество опций. Ниже мы используем PeekChar(), чтобы выяснить, имеет ли поток еще данные, и в том случае, когда он их имеет, использовать ReadByte() для получения значения. Обратите внимание на то, что байты форматируются в шестнадцатиричном виде и между ними вставляются семь пробелов.

static void Main(string[] args) {

 // Открытие сеанса двоичной записи в файл.

 FileInfo f = new FileInfo("BinFile.dat");

 …

 // Чтение данных в виде "сырых" байтов.

 BinaryReader br = new BinaryReader(f.OpenRead());

 int temp = 0;

 while (br.PeekChar() != -1) {

  Console.Write("{0,7:x}", br.ReadByte());

  if (++temp == 4) {

   // Запись каждых 4 байтов в виде новой строки.

Console.WriteLine();

   temp = 0;

  }

 Console.WriteLine();

 }

}

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

Вывод этой программы показан на рис. 16.9.

Рис. 16.9. Чтение байтов из двоичного файла

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

publiс enum System.IO.NotifyFilters {

 Attributes, СreationTime,

 DirectoryName, FileName,

 LastAccess, LastWrite,

 Security, Size,

}

Первым делом для работы с типом FileSystemWatcher нужно установить свойство Path, с помощью которого можно указать имя (и место размещения) каталога, содержащего контролируемые файлы, и свойство Filter, с помощью которого определяются расширения контролируемых файлов.

После этого можно указать обработку событий Сhanged, Created и Deleted, которые работают в совокупности с делегатом FileSystemEventHandler. Этот делегат может вызывать любой метод, соответствующий следующему шаблону.

// Делегат FileSystemEventHandler должен указывать на методы,

// имеющие следующую сигнатуру.

void MyNotifacationiHandler(object source, FileSystemEventArgs e)

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

// Делегат RenamedEventHandler должен указывать на методы,

// имеющие следующую сигнатуру.

void MyNotificationHandler(object source, RenamedEventArgs e)

Для иллюстрации процесса мониторинга файлов предположим, что мы создали на диске C новый каталог с именем MyFolder, cодержащий различные файлы *.txt (назовите их так, как пожелаете). Следующее консольное приложение осуществляет мониторинг файлов *.txt а каталоге MyFоlder и выводит сообщения о событиях, соответствующих созданию, удалению, изменению или переименованию файлов.

static void Main(string[] args) {

 Console.WriteLine("***** Чудесный монитор файлов *****\n");

 // Установка пути для каталога наблюдения.

 FileSystemWatcher watcher = new FileSystemWatcher();

 try {

  watcher.Path = @"C:\MyFolder";

 } catch(ArgumentException ex) {

  Console.WriteLine(ex.Message);

  return;

 }

 // Установка фильтров наблюдения.

 watcher.NotifyFilter = NotifyFilters.LastAccess | NotifyFilters.LastWrite | NotifyFilters.FileName | NotifyFilters.DirectoryName;

 // Наблюдение только за текстовыми файлами.

 watcher.Filter = "*.txt";

 // Добавление обработчиков событий.

 watcher.Changed += new FileSystemEventHandler(OnChanged);

 watcher.Created += new FileSystemEventHandler(OnChanged);

 watcher.Deleted += new FileSystemEventHandler(OnChanged);

 watcher.Renamed += new RenamedEventHandler(OnRenamed);

 // Начало наблюдения за каталогом.

 watcher.EnableRaisingEvents = true;

 // Ожидание сигнала пользователя для выхода из программы.

 Console.WriteLine(@"Нажмите 'q' для выхода из приложения.");

 while(Console.Read() != 'q');

}

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

static void OnChanged(object source, FileSystemEventArgs e) {

 // Уведомление об изменении, создании или удалении файла.

 Console.WriteLine("Файл {0} {1}!", e.FullPath, e.ChangeType);

}

static void OnRenamed(object source, RenamedEventArgs e) {

 // Уведомление о переименовании файла.

 Console.WriteLine("Файл {0} переименован в\n{1}",

 e.OldFullPath, e.FullPath);

}

Чтобы проверить работу этой программы, запустите приложение и откройте Проводник Windows. Попытайтесь переименовать, создать, удалить файлы *.txt в MyFolder или выполнить с ними какие-то другие действия, вы увидите, что консольное приложение реагирует на эти действия выводом различной информации о состоянии текстовых файлов (рис. 16.10).

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

Рис. 16.10. Наблюдение за текстовыми файлами

В завершение нашего обзора пространства имен System.IO давайте выясним, как осуществляется асинхронное взаимодействие с типами FileStream. Один из вариантов поддержки асинхронного взаимодействия в .NET вы уже видели при рассмотрении многопоточных приложений (см. главу 14). Ввиду того, что ввод-вывод может занимать много времени, все типы, производные от System.IO.Stream, наследуют множество методов, разрешающих асинхронную обработку данных. Как и следует ожидать, эти методы работают в связке с типом IAsyncResult.

public abstract class System.IO.Stream: MarshalByRefObject, IDisposable {

…

 public virtual IAsyncResult BeginRead(byte[] buffer, int offset, int count, AsyncCallback callback, object state);

 public virtual IAsyncResult BeginWrite(byte[] buffer, int offset, int count, AsyncCallback callback, object state);

 public virtual int EndRead(IAsyncResult asyncResult); public virtual void EndWrite(IAsyncResult asyncResult);

}

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

class Program {

 static void Main(string[] args) {

  Console.WriteLine("Старт первичного потока, ThreadID = {0}", Thread.CurrentThread.GetHashCode());

  // Следует использовать этот конструктор, чтобы получить

  // FileStream с асинхронным доступом для чтения и записи.

  FileStream fs = new FileStream('logfile.txt", FileMode.Append, FileAccess.Write, FileShare.None, 4096, true);

  string msg = "это проверка";

  byte[] buffer = Encoding.ASCII.GetBytes(msg);

  // Начало асинхронной записи.

  // По окончании вызывается WriteDone.

  // Объект FileStream передается методу обратного вызова,

  // как информация состояния.

  fs.BeginWrite(buffer, 0, buffer.Length, new AsyncCallback(WriteDone), fs);

 }

 private static void WriteDone(IAsyncResult ar) {

  Console.WriteLine("Метод AsyncCallback для ThreadID = {0}", Thread.CurrentThread.GetHashCode());

  Stream s = (Stream)ar.AsyncState;

  s.EndWrite(ar);

  s.Close();

 }

}

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

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

Эта глава начинается с рассмотрения типов Directory(Info) и File(Info) (а также нескольких новых членов типа File, появившихся в .NET 2.0). Вы узнали о том, что эти классы позволяют работать с физическими файлами или каталогами на жестком диске. Затем был рассмотрен ряд типов (в частности, FileStream), полученных из абстрактного класса Stream. Поскольку типы, производные от Stream, работают с потоком "сырых" байтов, пространство имен System.IO предлагает множество типов ввода-вывода (StreamWriter, StringWriter, BinaryWriter и т.п.), упрощающих процесс.

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

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

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

Термин сериализация означает процесс переноса состояния объекта в поток, Соответствующая сохраненная последовательность данных содержит всю информацию, необходимую для реконструкции объекта, если в дальнейшем возникает необходимость в его использовании. С помощью такой технологии очень просто сохранять огромные объемы данных (в самых разных форматах). Во многих случаях сохранение данных приложения с помощью сервиса сериализации оказывается намного менее неуклюжим, чем прямое использование средств чтения/записи, предлагаемых в рамках пространства имен 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;

Независимо от того, какой формат вы выберете для использования, все они получаются прямо из 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.

Теперь предположим, что вы хотите прочитать сохранённые данные 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

Следующим вариантом является тип SoapFormatter. Тип SoapFormatter сохраняет объектный граф в сообщении SOAP (Simple Object Access Protocol – простой протокол доступа к объектам), что делает этот вариант форматирования прекрасным выбором при передаче объектов средствами удаленного взаимодействия по протоколу HTTP. Если вы не знакомы со спецификациями SOAP, не волнуйтесь. В сущности, SOAP определяет стандартный процесс, с помощью которого можно вызывать методы не зависящим от платформы и ОС способом (мы рассмотрим SOAP чуть более подробно в последней главе этой книги при обсуждении Web-сервисов XML).

В предположении о том, что вы установили ссылку на компоновочный блок System.Runtime.Serialization.Formatters.Soap.dll, можно реализовать сохранение и восстановление JamesBondCar в формате сообщения SOAP с помощью замены BinaryFormatter на SoapFormatter. Рассмотрите следующий программный код, который выполняет сериализацию объекта в локальный файл с именем CarData.soap.

using System.Runtime.Serialization.Formatters.Soap;

…

static void Main(string[] args) {

 …

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

 SoapFormatter soapFormat = new SoapFormatter();

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

 soapFormat.Serialize(fStream, jbc);

 fStream.Close();

 Console.ReadLine();

}

Как и ранее, здесь просто используются Serialize() и Deserialize() для перемещения объектного графа в поток и восстановления его из потока. Если открыть полученный файл *.soap, вы увидите в нем элементы XML, представляющие значения JamesBondCar и взаимосвязи между объектами графа (с помощью лексем #ref). Рассмотрите следующий фрагмент XML-кода, соответствующий конечному результату (для краткости здесь опущены указания на пространства имен XML).

‹SOAP-ENV:Envelope xmlns:xsi="…"›

 ‹SOAP-ENV:Body›

  ‹a1:JamesBondCar id="ref-1" xmlns:a1="…"›

   ‹canFly›true‹/canFly›

   ‹canSubmerge›false‹/canSubmerge›

   ‹theRadio href="#ref-3"/›

   ‹isHatchBack›false‹/isHatchBack›

  ‹/a1:JamesBondCar›

  ‹a1:Radio id="ref-3" xmlns:a1="…"›

   ‹hasTweeters›true‹/hasTweeters›

   ‹hasSubWoofers›false‹/hasSubWoofers›

   ‹stationPresets href="ref-4"/›

  ‹/a1:Radio›

  ‹SOAP-ENC:Array id="ref-4" SOAP-ENC:arrayType="xsd:dooble[3]"›

   ‹item›89.3‹/item›

   ‹item›105.1‹/item›

   ‹item›97.1‹/item›

  ‹/SOAP-ENC:Array›

 ‹/SOAP-ENV:Body›

 ‹/SOAP-ENV:Envelope›

Вдобавок к 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-элементов (например, с требованием о том, что все открываемые элементы должны иметь закрывающие их дескрипторы). Скорее, допустимость документов связана с правилами форматирования (например, поле 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

Теперь вы знаете, как сохранить в потоке отдельный объект, и давайте выясним, как сохранить множество объектов. Заметим, что метод Serialize() интерфейса IFormatter не позволяет указать произвольное число объектов (а только один System.Object). Аналогично, возвращаемым значением Deserialize() тоже является один System.Object.

public interface IFormatter {

 …

 object Deserialize(System.IO.Stream serializationStream);

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

}

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

Предположим, что в класс JamesBondCar был добавлен конструктор с двумя аргументами, чтобы можно было установить некоторые начальные данные состояния (обратите внимание на то, что конструктор, заданный по умолчанию, был возвращен на место в соответствии с требованиями XmlSerializer),

[Serializable,

XmlRoot(Namespace = "http://www.intartechtraining.com")]

public class JamesBondCar: Car {

 public JamesBondCar(bool skyWorthy, bool seaWorthy) {

  canFly = skyWorthy; canSubmerge = seaWorthy;

 }

 // Для XmlSerializer нужен конструктор, заданный по умолчанию!

 public JamesBondCar(){}

 …

}

При этом вы сможете сохранить любое число объектов JamesBondCar так.

static void Main(string[] args) {

 …

 // Сохранение объекта List‹› с набором JamesBondCar.

 List‹JamesBondCar› myCars = new List‹JamesBondCar›();

 myCars.Add(new JamesBondCar(true, true));

 myCars.Add(new JamesBondCar(true, false));

 myCars.Add(new JamesBondCar(false, true));

 myCars.Add(new JamesBondCar(false, false));

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

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

 xmlFormat.Serialize(fStream, myCars);

 fStream.Close();

 Console.ReadLine();

}

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

statiс void Main (string[] args) {

 …

 // Сохранение объекта List‹›(myCars) в двоичном формате.

 list‹JamesBondCar› myCars = new List‹JamesBondCar›();

 …

 BinaryFormatter binFormat = new BinaryFormatter();

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

 binFormat.Serialize(fStream, myCars);

 fStream.Close();

 Console.ReadLine();

}

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

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

В большинстве случаев типовая схема сериализации, предлагаемая платформой .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.

Объекты, обозначаемые атрибутом [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.

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

[Serializable]

class UserPrefs {

 public string objVersion = "1.0";

 public ConsoleColor BackgroundColor;

 public ConsoleColor ForegroundColor;

 public UserPrefs() {

  BackgroundColor = ConsoleColor.Black;

  ForegroundColor = ConsoleColor.Red;

 }

}

Теперь предположим, что у нас есть приложение, в котором выполняется сериализация экземпляра этого класса с помощью BinaryFormatter.

static void Main(string[] args) {

 UserPrefs up = new UserPrefs();

 up.BackgroundColor = ConsoleColor.DarkBlue;

 up.ForegroundColor = ConsoleColor.White;

 // Сохранение экземпляра UserPrefs в файле.

 BinaryFormatter binFormat = new BinaryFormatter();

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

 birFormat.Serialize(fStream, up);

 fStream.Сlose();

 Console.ReadLine();

}

К этому моменту экземпляр UserPrefs (версии 1.0) сохранен в C:\user.dat. Но давайте добавим в определение класса UserPrefs два новых поля.

[Serializable]

class UserPrefs {

 public string objVersion = "2.0";

 public ConsoleColor BackgroundColor;

 public ConsoleColor ForegroundColor;

 // Являются новыми!

 public int BeepFreq;

 public string ConsoleTitle;

 public UserPrefs() {

  BeepFreq = 1000;

  ConsoleTitle = "Моя консоль";

  BackgroundColor = ConsoleColor.Black;

  ForegroundColor = ConsoleColor.Red;

 }

}

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

static void Main(string[] args) {

 // Загрузка экземпляра UserPrefs (1.0) в память?

 UserPrefs up = null;

 BinaryFormatter binFormat = new BinaryFormatter();

 Stream fStream = new FileStream(@"C:\user.dat", FileMode.Open, FileAccess.Read, FileShare.None);

 up = (UserPrefs)binFormat.Deserialize(fStream);

 fStream.Close();

 Console.ReadLine();

}

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

Необработанное исключение: System.Runtime.Serialization.SerializationException. Член 'BeepFreq' в классе 'VersionedObject.UserPrefs' не присутствует в сохраненном потоке и не обозначен атрибутом System.Runtime.Serialization.OptionalFieldAttribute.

Проблема в том, что оригинальный объект UserPrefs, сохраненный в C:\user.dat, не сохранял два новых поля, присутствующих в обновленном определении класса (это поля BeepFreq и ConsoleTitle). Очевидно, что это настоящая проблема, поскольку для сохраняемого объекта вполне естественно эволюционировать в процессе существования.

До выхода .NET 2.0 единственной возможностью для учета того, что сохраненный объект может не иметь всех новых полей из обновленной и более поздней версии класса, была необходимость реализации ISerializable и осуществление контроля "вручную". Но с появлением .NET 2.0 новые поля могут явно обозначаться атрибутом [Optional Field] (определенным в рамках пространства имен System.Runtime.Serialization).

[Seriаlizable]

class UserPrefs {

 public ConsoleColor BackgroundColor;

 public ConsoleColor ForegroundColor;

 // Являются новыми!

 [OptionalField]

 public int BeepFreq;

 [OptionalField]

 public string ConsoleTitle;

 public UserPrefs() {

  BeepFreq = 1000;

  ConsoleTitle = ''Моя консоль";

  BackgroundColor = ConsoleColor.Black;

  ForegroundColor = ConsoleColor.Red;

}

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

Замечание. Следует понимать, что использование [OptionalField] не решает проблему версий сохраненных объектов полностью. Однако этот атрибут обеспечивает решение самой типичной проблемы (добавление новых полей данных). Для решения более сложных задан поддержки версий все же потребуется реализация интерфейса ISerializable.

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

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

Вы также узнали о том, что процесс сериализации допускает пользовательскую настройку в рамках двух возможных подходов. Во-первых, у вас есть возможность реализовать интерфейс ISerializable (с поддержкой специального приватного конструктора), чтобы влиять на то. как средства форматирования сохраняют поступающие данные. Во-вторых, вы можете использовать множество новых атрибутов, появившихся в .NET 2.0, которые упрощают процесс сериализации с пользовательскими настройками. Следует просто применить один из атрибутов [OnSerializing], [OnSerialized], [OnDeserializing] или [OnDeserialized] к членам, получающим параметр StreamingContext, и форматтер обработает их соответствующим образом. Завершается глава обсуждением еще одного атрибута, [OptionalField], который может использоваться для поддержки версий сериализации типов.

Разработчики, не имеющие опыта работы с платформой .NET, обычно относят .NET только к средствам создания Интернет-приложений (поскольку ".NET"' часто ассоциируется с "Интернет" и соответствующим программным обеспечением. Вы уже имели возможность убедиться в том, что это далеко не так. Создание Web-приложений является лишь одной и очень узкой (но широко разрекламированной) возможностью платформы .NET. В русле этой информации многие разработчики .NET, не имеющие достаточного опыта, склонны предполагать, что Web-сервисы XML обеспечивают единственный способ взаимодействия с удаленными объектами. Это тоже не соответствует действительности. Используя слой удаленного взаимодействия .NET, можно строить одноранговые распределенные приложения, не имеющие ничего общего с HTTР или XML (если вы этого захотите).

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

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

• Два домена приложения определены в рамках одного и того же процесса (и поэтому на одной и той же машине).

• Два домена приложения определены в разных процессах на одной и той же машине.

• Два домена приложения определены в разных процессах на разных машинах.

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

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

Таблица 18.1. Пространства имен .NET для поддержки возможностей удаленного взаимодействия

Когда клиенты и серверы обмениваются информацией через границы приложений, среда 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 является форматтер. Типы 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 уже не будут вам казаться столь запутанными.

В рамках платформы .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-объект и когда этот объект должен стать кандидатом для участия в процедуре сборки мусора на сервере. На первый взгляд, такая постановка вопроса может показаться странной, поскольку, очевидно. 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.

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

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

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

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

public enum WellKnownObjectMode {

 SingleCall,

 Singleton

}

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

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

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

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

• Клиент. Этот компоновочный блок представляет сущность (например, приложение Windows Forms или консольное приложение), заинтересованную в получении доступа к удаленному объекту.

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

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

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

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

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

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

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

Замечание. Чтобы выяснить, как реализовать общие компоновочные блоки в рамках указанных выше альтернативных подходов, прочитайте книгу Tom Barnaby, Distributed .NET Programming in C# (Apress, 2002).

Ничто не принесет большей радости, чем создание реального распределенного приложения на новой платформе. Чтобы показать, как быстро можно создать и запустить приложение, использующее слой удаленного взаимодействия .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. Вывод клиента

Итак, объявляя существование удаленного типа, сервер использует тип System. Runtime.Remoting.Channels.ChannelServices. Тип ChannelServices предлагает небольшой набор статических методов, призванных обеспечить содействие в процессе регистрации канала удаленного взаимодействия и обнаружения указанного URL. Главные члены данного типа описаны в табл. 18.4.

Вдобавок к методам RegisterChannel() и UnregisterChannel() с их ясными названиями, тип ChannelServices определяет свойство RegisteredChannels. Этот член возвращает массив интерфейсов IChannel, каждый из которых представляет дескриптор соответствующего канала из тех, которые зарегистрированы в данном домене приложения.

Таблица 18.4. Подборка членов типа ChannelServices

Определение интерфейса IChannel оказывается исключительно простым.

publiс interface IChannel {

 string ChannelName { get; }

 int ChannelPriority { get; }

 string Parse(string url, ref String objectURI);

}

Как видите, каждый канал получает понятное строковое имя, а также свой уровень приоритета. Например, если добавить в метод Main() приложения SimpleRemoteObjectClient следующую) программную логику

// Список всех зарегистрированных каналов.

IChannel[] сhannelObjs = ChannelServices.RegisteredChannels;

foreach (IChannel i in channelObjs) {

 Console.WriteLine("Имя канала: {0}", i.ChannelName);

 Console.WriteLine("Приоритет: {0}", i.ChannelPriority);

}

то в окне консоли клиента вы увидите вывод, подобный показанному на рис. 18.4.

Рис. 18.4. Список каналов в окне клиента

Другим ключевым типом удаленного взаимодействия является тип RemotingConfiguration, который, в соответствии со своим названием, используется для настройки различных параметров приложения удаленного взаимодействия. Вы уже видели этот тип в работе на стороне сервера (при вызове метода RegisterWellKnownServiceType()). Другие заслуживающие внимания статические члены этого типа описываются в табл. 18.5, а возможности применения некоторых из этих членов будут продемонстрированы в оставшейся части этой главы.

Таблица 18.5. Члены типа RemotingConfiguration 

Напомним, что слой удаленного взаимодействия .NET различает два вида MBR-объектов: WKO (активизируются сервером) и САО (активизируются клиентом). К тому же, WKO-тип может быть активизирован либо как синглет, либо как объект одиночного вызова. Используя функциональные возможности типа RemotingConfiguration, вы можете динамически получить такую информацию в среде выполнения. Например, если добавить в метод Main() приложения SimpleRemoteObjectServer следующие строки программного кода:

static void Main(string[] args) {

 …

 // Установка понятного имени для данного приложения сервера.

 RemotingConfiguration.ApplicationName = "Первое серверное приложение";

 Console.WriteLine("Имя приложения: {0}", RemotingConfiguration.ApplicationName);

 // Получение массива типов WellKnownServiceTypeEntry,

 // представляющих зарегистрированные WKO-объекты.

 WellKnownServiceTypeEntry[] WKOs = RemotingConfiguration.GetRegisteredWellKnownServiceTypes();

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

 foreach(WellKnownServiceTypeEntry wko in WKOs) {

  Console.WriteLine("Имя блока, содержащего WKO: {0}", wko.AssemblyName);

  Console.WriteLine("URL данного WKO: {0}", wko.ObjectUri);

  Console.WriteLine("Тип WKO: {0}", wko.ObjectType);

  Console.WriteLine("Режим активизации WKO: {0}", wko.Mоde);

 }

}

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

Рис. 18.5. Статистика сервера

Другим важным методом типа RemotingConfiguration является метод Configure(). Вскоре вы сможете убедиться, что этот статический член позволяет доменам приложений клиента и сервера использовать файлы конфигурации удаленного взаимодействия.

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

// Синглеты могут обслуживать множество клиентов.

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

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

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

// WKO-типы одиночного вызова связаны с клиентом

// отношением "один к одному".

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

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

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

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

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

2. Скопируйте компоновочные блоки SimpleRemoteObjeсtServer.exe и SimpleRemotingAsm.dll в эту папку.

3. Откройте проект SimpleRemoteObjectClient и измените URL активизации в соответствии с именем удаленной машины, например:

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

object remoteObj = Activator.GetObject(typeof(SimpleRemotingAsm.RemoteMessageObject), "httр://ИмяУдаленнойМашины:32469/RemoteMsgObj.soap");

4. Запустите приложение SimpleRemoteObjectServer.exe на машине сервера.

5. Запустите приложение SimpleRemoteObjectClient.exe на машине клиента.

6. Откиньтесь на спинку кресла, расслабьтесь и улыбнитесь.

Замечание. Вместо понятного имени Машины URL активизации может указывать ее IP-адрес.

В настоящий момент ваш удаленный объект доступен через сетевой протокол HTTP. Как уже упоминалось выше, этот протокол вполне совместим с брандмауэром, но генерируемые при этом пакеты SOAP немного "раздуты" (по причине представления данных в формате XML). Чтобы уменьшить сетевой трафик, можно изменить компоновочные блоки клиента и сервера так, чтобы в них использовался TCP-канал и, следовательно, тип BinaryFormatter. Вот подходящая модификация компоновочного блока сервера.

Замечание. Для файлов с определениями объектов, доступных по TCP-каналам о заданным URI, чаще всего (но не обязательно) используется расширение *.rem (от remote – удаленный).

// Корректировки для сервера.

using System.Runtime.Remoting.Channels.Tcp;

…

static void Main(string[] args) {

 …

 // Создание нового TcpChannel

 TcpChannel с = new TcpChannel(32469);

 ChannelServises.RegisterChannel(c);

 // Регистрация WKO-объекта в режиме синглета.

 RemotingConfiguration.RegisterWellKnownServiceType(typeof(SimpleRemotingAsm.RemoteMessageObject), "RemoteMsgObj.rem", WellKnownObjectMode.SingleCall);

 Console.ReadLine();

}

Здесь в слое удаленного взаимодействия .NET регистрируется тип System. Runtime.Remoting.Channels.Tcp.TcpChannel. Кроме того, изменен URI-объект (теперь для него задано более общее имя RemoteMsgObj.rem вместо *.soap, что явно указывало на использование SOAP). Модификация приложения клиента так же проста.

// Корректировки для клиента.

using System.Runtime.Remoting.Channels.Тcр;

…

static void Main(string[] args) {

 …

 // Создание нового TcpChannel

 TcpChannel с = new TcpChannel();

 ChannelServices.RegisterChannel(c);

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

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

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

 RemoteMessageObject simple = (RemoteMessageObject)remoteObj;

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

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

 Console.ReadLine();

}

Единственным заслуживающим внимания моментом здесь является то, что URL активизации клиента теперь должен содержать признак канала tcp://, а не http://. Во всем остальном программная логика здесь оказывается идентичной программной логике HttpChannel,

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

Перед тем как перейти к обсуждению файлов конфигурации удаленного взаимодействия, напомним, что .NET 2.0 предлагает тип IpcChannel, обеспечивающий самый быстрый из возможных способов взаимодействия приложений на одной машине. Задачей данной главы является изучение возможностей построения распределенных приложений, выполняемых не на одном, а на множестве компьютеров. Поэтому по поводу использования IpcChannel обратитесь к документации .NET Framework 2.0 SDK (как и следует ожидать, соответствующий программный код будет почти идентичен программному коду, необходимому для работы с HttpChannel и TcpChannel).

Итак, вы успешно построили распределённое приложение, используя слой удаленного взаимодействия .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›

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

// "Жестко" заданная программная логика сервера 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 удаленного взаимодействия. В отличие от файлов конфигурации сервера, в файлах конфигурации клиента для идентификации имени 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-тип можно активизировать только с помощью конструктора типа, заданного по умолчанию.

• Экземпляр WKO-типа создается на сервере при первом запросе члена этого типа клиентом,

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

Чтобы проиллюстрировать соответствующую конструкцию и использование САО-типов, модифицируем наш уже имеющийся "автомобильный" компоновочный блок. В нашем MBR-классе CarProvider определим дополнительный конструктор, позволяющий клиенту передать массив типов JamesBondCar, предназначенных для размещения в обобщенном списке List‹›.

public class CarProvider: MarshalByRefObject {

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

 public CarProvider(JamesBondCar[] theCars) {

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

  Console.WriteLine("с помощью пользовательского конструктора');

  theJBCars.AddRange(theCars);

 }

 …

}

Чтобы позволить вызывающей стороне активизировать CarProvider с помощью нового конструктора, нужно построить приложение сервера, которое зарегистрирует CarProvider, как САО-тип, а не как WKO-тип. Это можно сделать программно с помощью метода, аналогичного RemotingConfiguration.RegisterActivatedServiceType(), или с помощью файла *.config на стороне сервера. Чтобы "жестко" задать имя CAO-объекта в программном коде сервера, передайте информацию типа или типов (после создания и регистрации канала), как предлагается ниже.

// "Жёсткое" указание того, что CarProvider является САО-типом.

RemotingConfiguration.RegisterActivatedServiceType(typeof(CAOCarGeneralAsm.CarProvider));

Если вы предпочтете использовать файл *.config, вместо элемента ‹wellknown› используйте элемент ‹activated›, как показано ниже.

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

   ‹service›

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

   ‹/service›

   ‹channels›

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

   ‹/channels›

  ‹/application›

 ‹/system.runtime.remoting›

‹/configuration›

Наконец, нужно обновить приложение клиента, и не только с целью учета соответствующего файла *.config (или программных изменений в базовом коде) для запроса доступа к удаленному САО-объекту, но и с тем, чтобы вызвать созданный пользовательский конструктор типа CarProvider. Вот как должен выглядеть модифицированный метод Main() на стороне клиента.

static void Main(string[] args) {

 // Чтение обновленного файла *.config.

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

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

 JamesBondCar[] cars = {

  new JamesBondCar ("Viper", 100, true, false),

  new JamesBondCar("Shaken", 100, false, true),

  new JamesВоndCar("Stirred", 100, true, true)

 };

 // Теперь вызов пользовательского конструктора.

 CarProvider ср = new CarProvider(cars);

 …

}

Обновленный файл *.сonfig клиента также должен использовать элемент ‹activated›, а не элемент ‹wellknown›. Кроме того, свойство url элемента ‹client› теперь должно указывать адрес зарегистрированного САО-объекта. Напомним, что при регистрации типа CarProvider сервером в виде WKO-объекта, клиент указывал соответствующую информацию в рамках элемента ‹wellknown›.

‹configuration›

 ‹system.runtime.remoting›

  ‹application›

   ‹client displayName = "CarClient" url = "tcp://localhost:32469"›

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

   ‹/client›

   ‹channels›

    ‹channel ref="tcp"/›

   ‹/channels›

  ‹/application›

 ‹/system.runtime.remoting›

‹/configuration›

Чтобы "жестко" запрограммировать запрос САО-типа клиентом, можете использовать метод RegistrationServices.RegisterActivatedClientType(), как показано ниже.

static void Main(string[] args) {

 // Использование "жестких" значений.

 RemotingConfiguration.RegisterActivatedClientType(typeof(CAOCarGeneralAsm.CarProvider), "tcp://localhost:32469");

}

Запустив на выполнение обновленные компоновочные блоки сервера и клиента, вы с удовлетворением обнаружите, что можете передать свой пользовательский массив типов JamesBondCar удаленному объекту CarProvider через перегруженный конструктор.

Исходный код. Проекты CAOCarGeneralAsm, CAOCarProviderServer и CAOCarProviderCIient размещены в подкаталоге, соответствующем главе 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-синглет может выйти за рамки отведенного для процесса времени. Надеюсь, вы уловили общую идею, хотя здесь, конечно, более "элегантным" решением является создание нового потока выполнения.

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

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

public interface System.Runtime.Remoting.Lifetime.ISponsor {

 TimeSpan Renewal(ILease lease);

}

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

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

Для этого заинтересованная сторона должна получить ссылку ILease (с помощью наследуемого метода GetLifetimeService() на стороне сервера или статического метода RemotingServices.GetLifetimeService() на стороне клиента) и вызвать Register().

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

CarSponsor mySponsor = new CarSponsor();

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

itfLeaseInfo.Register(mySponsor);

// Регистрация спонсора на стороне клиента.

CarSponsor mySponsor = new CarSponsor();

CarProvider cp = new CarProvider(cars);

ILease itfLeaseInfo = (ILease)Remoting.Services.GetLifetimeService(cp);

itfLeaseInfo.Register.(mySponsor);

В любом случае, если клиент или сервер желают отменить спонсорство, это можно сделать с помощью метода ILease.Unregister(), например:

// Отключение спонсора для данного объекта.

itfLeaseInfo.Unregister(mySponsor);

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

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

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

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

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

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

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

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

Возможно, идеальным хостом для удаленных объектов является сервис 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 (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.

Предположим, что 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] только тогда, когда вызывающей стороне действительно позволяется вызвать эти методы и "забыть" об этом.

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

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

Если вы прочитали предыдущие 18 глав, вы должны иметь солидную базу дли использования языка программирования C# и архитектуры .NET. Вы, конечно же, можете применить полученные знания для построения консольных приложений следующего поколения (как скучно!), но вас, наверное, больше интересует создание привлекательного графического интерфейса пользователя (GUI), который позволит пользователям взаимодействовать с вашей системой.

Эта глава является первой из трех глав, в которых обсуждается процесс построения традиционных приложений на основе использования так называемых форм. Вы узнаете, как создать "высокохудожественное" главное окно, используя классы Form и Application. В этой главе также показано, как в контексте GUI-окружения выполнить захват пользовательского ввода и ответить на него (т.е. обработать события мыши и клавиатуры). Наконец, вы узнаете, как вручную или с помощью инструментов проектирования, встроенных в Visual Studio 2005, конструировать системы меню, панели инструментов, строки состояния и интерфейс MDI (Multiple Document Interface – многодокументный интерфейс приложения).

Как и любое другое пространство имен, System.Windows.Forms компонуется из различных классов, структур, делегатов, интерфейсов и перечней. Хотя различие между консольным (CUI) и графическим (GUI) интерфейсами, на первый взгляд, кажется подобным различию между ночью и днем, фактически для создания приложения Windows Forms необходимо только освоение правил манипуляции новым множеством типов с использованием того синтаксиса CIL, который вы уже знаете. С высокоуровневой точки зрения, сотни типов пространства имен System.Windows.Forms можно объединить в следующие большие категории.

• Базовая инфраструктура. Это типы, представляющие базовые операции программы .NET Forms (Form, Application и т.д.), а также различные типы, обеспечивающие совместимость с разработанными ранее элементами управления ActiveX.

• Элементы управления. Все типы, используемые для создания пользовательского интерфейса (Button, MenuStrip, ProgressBar, DataGridView и т.д.), являются производными базового класса Control. Элементы управления конфигурируются в режиме проектирования и оказываются видимыми (по умолчанию) во время выполнения.

• Компоненты. Это типы, не являющиеся производными базового класса Control, но тоже предлагающие визуальные инструменты (ToolTip, ErrorProvider и т.д.) для программ .NET Forms. Многие компоненты (например, Timer) во время выполнения невидимы, но они могут конфигурироваться визуально в режиме проектирования.

• Диалоговые окна общего вида. Среда Windows Forms предлагает целый ряд стандартных заготовок диалоговых окон для выполнения типичных действий (OpenFileDialog, PrintDialog и т.д.). Кроме того, вы можете создавать свои собственные пользовательские диалоговые окна, если стандартные диалоговые окна по какой-то причине вам не подойдут.

Поскольку общее число типов в System.Windows.Forms намного больше 100, кажется нерациональным (даже с точки зрения экономии бумаги) предлагать здесь описание всех элементов семейства Windows Forms. В табл. 19.1 описаны наиболее важные из типов System.Windows.Forms, предлагаемых в .NET 2.0 (все подробности можно найти в документации .NET Framework 2.0 SDK).

Таблица 19.1. Базовые типы пространства имен System.Windows.Forms

Замечание. Вдобавок к System.Windows.Forms, компоновочный блок System.Windows. Forms.dll определяет и другие пространства имен, предназначенные для поддержки элементов графического интерфейса пользователя. Соответствующие дополнительные типы используются, в основном, внутренними механизмами создания форм и/или разработки Visual Studio 2005. По этой причине мы ограничимся рассмотрением базового пространства имен System.Windows.Forms.

При построении приложения 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 давайте расширим тип 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));

 }

}

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

delegate void EventHandler(object sender, EventArgs e);

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

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

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

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

Теперь, когда вы понимаете роль типа Application, следующей вашей задачей является непосредственное рассмотрение функциональных возможностей класса Form. Как и следует ожидать, класс Form наследует большинство своих функциональных возможностей от родительских классов. На рис. 19.3 показано окно Object Browser (в Visual Studio 2005), в котором отображается цепочка наследования производного от Form типа (вместе с набором реализованных интерфейсов).

Рис. 19.3. Происхождение типа Form

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

Вы, наверное, сами понимаете, что подробное описание каждого члена всех классов в цепочке наследования Form потребует отдельной большой книги. Важно понять общие характеристики поведения, предлагаемого типами Control и Form. Bсe необходимые подробности о соответствующих классах вы сможете найти в документации .NET Framework 2.0 SDK.

Таблица 19.3. Базовые классы из цепочки наследования Form

Класс 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, давайте построим новую форму, способную обеспечивать следующее.

• Отвечать на события 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. Целью является отображение текущих координат (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

Если вы имеете опыт программирования интерфейсов пользователя с помощью таких пакетов разработки, как 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.

Любой тип Form проекта Windows Forms в Visual Studio 2005 представлен двумя связанными C#-файлами, в чем можно убедиться непосредственно, заглянув в окно Solution Explorer (рис. 19.10).

Рис. 19.10. Каждая форма является композицией двух файлов *.cs

Щелкните правой кнопкой мыши на пиктограмме Form1.cs и в появившемся контекстном меню выберите View Code (Просмотр программного кода). Вы увидите программный код парциального класса, содержащего обработчики событий формы, конструкторы, переопределения и другие члены созданного вами класса (заметьте, что здесь имя исходного класса Form1 было изменено на MainWindow с помощью выбора Rename из меню Refactor).

namespace MyVisualStudioWinApp {

 public partial class MainWindow: Form {

  public MainWindow() {

   InitializeComponent();

  }

 }

}

Конструктор, заданный формой по умолчанию, вызывает метод InitializeComponent(), определенный в соответствующем файле *.Designer.cs. Этот метод создается в Visual Studio 2005 автоматически, и в нем автоматически отражаются все модификации выполняемые вами в окне проектирования формы.

Для примера перейдите снова на вкладку окна проектирования формы и найдите свойство Text в окне свойств. Укажите для этого свойства новое значение (например, Мое тестовое окно). Теперь откройте файл Form1.Designer.cs и убедитесь в том, что метод InitializeComponent() соответствующим образом изменен.

private void InitializeComponent() {

 …

 this.Text = "Мое тестовое окно";

}

Кроме поддержки InitializeComponent(), файл *.Designer.cs определяет члены-переменные, представляющие элементы управления, размещенные в окне проектирования формы. Снова для примера перетащите элемент управления Button (Кнопка) в окно проектирования формы. В окне свойств с помощью свойства Name измените имя соответствующей переменной с button1 на btnTestButton.

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

Обратите внимание на то, что в окне свойств есть кнопка с изображением молнии. Вы, конечно, можете вручную создать программный код, обеспечивающий обработку событий уровня формы, (как это было сделано в предыдущих примерах), но эта кнопка позволяет обработать событие для данного элемента управления "визуально". Из раскрывающегося списка (вверху окна свойств) выберите элемент управления, который должен взаимoдeйствoвaть с формой, найдите событие, которое вы хотите обработать, и напечатайте имя, которое должно использоваться для обработчика события (или выполните двойной щелчок на имени события, чтобы сгенерировать типовое имя в виде ИмяЭлемента_ИмяСобытия).

Если задать обработку события Click для элемента управления Button, в файле Form1.cs появится следующий обработчик событий.

public partial class MainWindow: Form {

 public MainWindow {

  InitializeComponent();

 }

 private void btnButtonTest_Click(object sender, EventArgs e) {}

}

Файл Form1.Designer.cs будет содержать необходимую инфраструктуру и описание соответствующего члена-переменной.

partial class MainWindow {

 …

 private void InitializeComponent() {

  …

  this.btnButtonTest.Click += new System.EventHandler(this.btnButtonTest_Click);

 }

 private System.Windows.Forms.Button btnButtonTest;

}

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

Кроме файлов, связанных с формой, Windows-приложение Visual Studio 2005 определяет еще один класс, представляющий объект приложения (т.е. тип, определяющий метод Main()). Обратите внимание на то, что в следующем методе Main() вызывается Application.EnableVisualStyles(), а также Application.Run().

static class Program {

 [STAThread]

 static void Main() {

  Application.EnableVisualStyles();

  Application.Run(new MainWindow());

 }

}

Замечание. Атрибут [STAThread] дает среде CLR указание обрабатывать все устаревшие COM-объекты (включая элементы управления ActiveX), используя STA-управление (SingleThreaded Apartment – однопоточное размещение). Если вы имеете опыт использования COM, вы должны знать, что STA-управление используется для того, чтобы доступ к COM-типу выполнялся в синхронном (а значит, безопасном в отношении потоков) режиме.

Наконец, если Заглянуть в окно Solution Explorer, вы увидите, что проект Windows Forms автоматически ссылается на целый ряд компоновочных блоков, среди которых будут System.Windows.Forms.dll и System.Drawing.dll.

Напомним, что подробное обсуждение System.Drawing.dll предполагается в следующей главе.

В рамках платформы .NET 2.0 рекомендуемым элементом управления для создания системы меню является MenuStrip. Этот элемент управления позволяет создавать как "обычные" пункты меню, такие как Файл>Выход, так и пункты меню, представляющие собой любые подходящие элементы управления. Вот некоторые общие элементы интерфейса, которые могут содержаться в MenuStrip.

• ToolStripMenuItem – традиционный пункт меню.

• ToolStripComboBox – встроенный элемент ComboBox (комбинированное окно).

• ToolStripSeparator – простая линия, разделяющая содержимое.

• ToolStripTextBox – встроенный элемент TextBox (текстовое окно).

С точки зрения программиста, элемент управления MenuStrip содержит строго типизированную коллекцию ToolStripItemCollection. Подобно другим типам коллекции, этот объект поддерживает методы Add(), AddRange(), Remove() и свойство Count. Эта коллекция обычно заполняется не напрямую, а с помощью различных инструментов режима проектирования, но если требуется, то есть возможность обработать ее и вручную.

Чтобы привести пример использования элемента управления MenuStrip, создайте новое приложение Windows Forms с именем MenuStripApp. Поместите элемент управления MenuStrip в форму в окне проектирования, присвоив ему имя mainMenuStrip. В результате в файл *.Designer.cs добавится новая переменная.

private System.Windows.Forms.MenuStrip mainMenuStrip;

Элемент управления MenuStrip имеет очень широкие возможности настройки в режиме проектирования в Visual Studio 2005. Например, вверху у этого элемента управления есть маленькая пиктограмма стрелки, в результате выбора которой появляется контекстно-зависимый "встроенный" редактор содержимого, как показано на рис. 19.11.

Рис. 19.11. "Встроенный" редактор MenuStrip

Такие контекстно-зависимые редакторы cодержимого поддерживаются многими элементами управления Windows Forms. Что же касается MenuStrip, то соответствующий редактор позволяет быстро сделать следующее.

• Вставить "стандартную" систему меню (File, Save, Tools, Help и т.д.), используя ссылку Insert Standard Items (Вставить стандартные элементы).

• Изменить стыковочное поведение MenuStrip.

• Отредактировать любой элемент MenuStrip (это просто "быстрая альтернатива" в отношении возможности выбора соответствующего конкретного элемента в окне свойств).

В этом примере мы проигнорируем возможности "встроенного" редактора, сосредоточившись на создании системы меню "вручную". Сначала в режиме проектирования выберите элемент управления MenuStrip и определите стандартное меню Файл>Выход, впечатав соответствующие имена в поле с подсказкой Type Here (Печатать здесь), рис. 19.12.

Рис. 19.12. Создание системы меню

Замечание. Вы, наверное, знаете, что символ амперсанда (&), размещенный перед буквой в строке элемента меню, задает комбинацию клавиш для быстрого вызова данного элемента. В этом примере указано &Файл>В&ыход, поэтому пользователь может активизировать меню Выход, нажав сначала ‹Alt+ф›, а затем ‹ы›.

Каждый элемент меню, введенный вами в режиме проектирования, представляется типом класса ToolStripMenuItem. Открыв свой файл *.Designer.cs, вы увидите там новые переменные для каждого из введенных элементов.

partial class MainWindow {

 private System.Windows.Forms.MenuStrip mainMenuStrip;

 private System.Windows.Forms.ToolStripMenuItem fileToolStripMenuItem;

 private System.Windows.Forms.ToolStripMenuItem exitToolStripMenuItem;

}

При использовании редактора меню метод InitializeComponent() соответственно обновляется. Для MenuStrip во внутреннюю коллекцию ToolStripItemCollection добавляется элемент, соответствующий новому пункту меню высшего уровня (fileToolStripMenuItem). Точно так же обновляется переменная fileToolStripMenuItem, для которой в ее коллекцию ToolStripItemCollection вставляется переменная exitToolStripMenuItem с помощью свойства DropDownItems.

private void InitializeComponent() {

 …

 //

 // menuStrip1

 //

 this.menuStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] { this.fileToolStripMenuItem });

 …

 //

 // fileToolStripMenuItem

 //

 this.fileToolStripMenuItem.DropDownItems.AddRange(new System.Windows.Forms.ToolStripItem[] { this.exitToolStripMenuItem });

 …

 //

 // MainWindow

 //

 this.Controls.Add(this.menuStrip1);

}

Наконец (что не менее важно), элемент управления MenuStrip добавляется в коллекцию элементов управления формы. Эта коллекции будет рассматриваться подробно в главе 21, а здесь важно отметить, чего элемент управления может быть видимым во время выполнения только в том случае, когда этот элемент присутствует в указанной коллекции.

Чтобы завершить создание программного кода нашего примера, вернитесь в режим проектирования и выполните обработку события Сlick для пункта меню Выход, используя кнопку событий в окне свойств. В сгенерированном обработчике событии выполните вызов ApplicationExit.

private void exitToolStripMenuItem_Click(object sender, EventArgs e) {

 Application.Exit();

}

Теперь вы можете скомпилировать и выполнить свою программу. Проверьте, что вы можете завершить работу приложения как с помощью выбора Файл>Выход из меню, так и с помощью нажатия ‹Аlt+ф›, а затем ‹ы› на клавиатуре.

Давайте создадим новый элемент меню наивысшего уровня, присвоив этому элементу имя Изменение Цвета фона. Подчиненным элементом в этом меню будет не пункт меню, а элемент ToolStripTextBox (рис. 19.13). Добавив новый элемент управления, измените его имя на toolStripTextBoxColor с помощью окна свойств.

Нашей целью является возможность выбора пользователем цвета (красный, зелёный, розовый и т.д.). значение которого будет установлено для свойства BackColor формы. Сначала обработайте событие LostFocus для нового члена. ToolStripTextBox в рамках конструктора формы (это событие происходит тогда, когда TextBox в ToolStrip перестает быть активным элементом интерфейса).

public MainWindow() {

 …

 toolStripTextBoxColor.LostFocus += new EventHandler(toolStripTextBoxColor_LostFocus);

}

Рис. 19.13. Добавление TextBox в MenuStrip

В сгенерированном обработчике события прочитайте строковые данные, введенные в ToolStripTextBox (с помощью свойства Text), и используйте метод System. Drawing.Color.FromName(). Этот статический метод возвращает тип Color, соответствующий известному строковому значению. Чтобы учесть возможность ввода пользователем неизвестного цвета (или любых других неподходящих данных), используется простая логика try/catch.

void toolStripTextBoxColor_LostFocus(object sender, EventArgs e) {

 try {

  BackColor = Color.FromName(toolStripTextBoxColor.Text);

 } catch {} // Просто игнорировать неправильные данные.

}

Запустите обновленное приложение снова и попробуйте ввести названия различных цветов. В результате правильного ввода вы должны увидеть изменение цвета фона формы. Чтобы получить информацию о допустимых названиях цветов, изучите информацию о типе System.Drawing.Color в окне обозревателя объектов (Object Browser) Visual Studio 2005 или в документации .NET Framework 2.0 SDK.

Рассмотрим теперь процедуру построения контекстно-зависимых меню (т.е. меню, раскрывающихся по щелчку правой кнопки мыши). Классом, используемым для построения контекстных меню в .NET 1.1. был класс ContextMenu, но в .NET 2.0 предпочтение отдается типу ContextMenuStrip. Подобно типу MenuStrip, тип ContextMenuStrip поддерживает ToolStripItemCollection для представления всех элементов меню (ToolStripMenuItem, ToolStripComboBox, ToolStripSeparator, ToolStripTextBox и т.д.).

Перетащите новый элемент управления ContextMenuStrip из панели инструментов в окно проектирования формы и измените имя этого элемента управления на fontSizeContextStrip с помощью окна свойств. Обратите внимание на то, что теперь дочерние элементы в ContextMenuStrip можно добавлять графически, почти так же, как при редактировании MenuStrip (очень приятное изменение по сравнению с методом, предлагавшимся в Visual Studio .NET 2003). Для нашего примера добавьте три элемента ToolStripMenuItem с названиями Крупный, Средний и Мелкий (рис. 19.14).

Рис. 19.14. Создание ContextMenuStrip

Это контекстное меню предназначено для того, чтобы пользователь мог выбрать размер шрифта для сообщения, отображаемого в области клиента формы. Чтобы упростить себе задачу, создайте тип перечня TextFontSize в рамках пространства имен MenuStripApp и объявите новый член-переменную этого типа в рамках Form (установив для переменной значение TextFontSize.FontSizeNormal).

namespace MainForm {

 // Вспомогательный перечень для размера шрифта.

 enum TextFontSize {

  FontSizeHuge = 30,

  FontSizeNormal = 20,

  FontSizeTiny = 8

 }

 public class MainForm: Form {

  // Текущий размер шрифта.

  private TextFontSize currFontSize = TextFontSize.FontSizeNormal;

  …

 }

}

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

private void MainWindow_Paint(object sender, PaintEventArgs e) {

 Graphics g = e.Graphics;

 g.DrawString("Щелкните здесь правой кнопкой мыши…", new Font("Times New Roman", (float)currFontSize), new SolidBrush(Color.Black), 50, 50);

}

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

private void ContextMenuItemSelection_Clicked(object sender, EventArgs e) {

 // Получение элемента ToolStripMenuItem,

 // на котором выполнен щелчок.

 ToolStripMenuItem miClicked = (ToolStripMenuItem)sender;

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

 if (miClicked.Name == "hugeToolStripMenuItem") currFontSize = TextFontSize.FontSizeHuge;

 if (miClicked.Name == "normalToolStripMenuItem") currFontSize = TextFontSize.FontSizeNormal;

 if (miClicked.Name == "tinyToolStripMenuItem") currFontSize = TextFontSize.FontSizeTiny;

 // Указание форме обновить представление.

 Invalidate();

}

Обратите внимание на то, что использование аргумента sender позволяет определить имя члена-переменной ToolStripMenuItem, чтобы установить размер текста. После этого вызов Invalidate() генерирует событие Paint, которое вызовет ваш обработчик события Paint.

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

this.ContextMenuStrip = this.fontSizeContextStrip;

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

Замечание. С помощью свойства Context MenuStrip в контекстное меню можно включить любой элемент управления. Например, если в диалоговом окне контекстного меню создать объект Button (Кнопка), то соответствующий пункт Меню будет отображаться только тогда, когда щелчок будет выполнен в рабочей области кнопки.

Члены типа ToolStripMenuItem позволяют проверить состояние элемента меню, сделать его доступным или скрытым. В табл. 19.11 даются описания некоторых из наиболее интересных свойств этого типа.

Таблица 19.11. Члены типа ToolStripMenuItem

Давайте расширим ваше контекстное меню так, чтобы в нем рядом с выбранным в настоящий момент пунктом меню отображалась отметка выбора. Установить отметку для данного элемента меню очень просто (для этого нужно установить значение свойства Checked равным true). Однако для того, чтобы проследить, какой пункт меню должен быть отмечен, потребуется дополнительная программная логика. Одним из возможных подходов здесь является определение специальной переменной ToolStripMenuItem, которая будет представлять элемент, отмеченный в настоящий момент.

public class MainWindow: Form {

 …

 // Указывает отмеченный элемент.

 private ToolStripMenuItem currentCheckedItem;

}

Напомним, что размером текста по умолчанию является TextFontSize.FontSizeNormal. С учетом этого начальным отмеченным элементам в ToolStripMenuItem должен быть normalToolStripMenuItem. Измените конструктор формы так, как показано ниже.

public MainWindow() {

 // Наследуемый метод для центрирования формы.

 CenterToScreen();

 InitializeComponent();

 // Установка отметки выбора для элемента меню 'Средний'.

 currentCheckedItem = normalToolStripMenuItem;

 currentCheckedItem.Checked = true;

}

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

private void ContextMenuItemSelection_Clicked(object sender, EventArgs e) {

 // Удаление отметки выбора для элемента.

 currentCheckedItem.Checked = false;

 …

 if (miClicked.Name == "hugeToolStripMenuItem") {

  currFontSize = TextFontSize.FontSizeHuge;

  currentCheckedItem = hugeToolStripMenuItem;

 }

 if (miClicked.Name = "normalToolStripMenuItem") {

  currFontSize = TextFontSize.FontSizeNormal;

  currentCheckedItem = normalToolStripMenuItem;

 }

 if (miClicked.Name == "tinyToolStripMenuItem") {

  currFontSize = TextFontSize.FontSizeTiny;

  currentCheckedItem = tinyToolStripMenuItem;

 }

 // Установка отметки выбора для нового элемента.

currentCheckedItem.Checked = true;

 …

}

На рис. 19.15 показан законченный проект MenuStripApp в действии.

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

Рис. 19.15. Установка и удаление отметок выбора для элементов ToolStripMenuItem

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

Хотя поддержка строк состояния (с помощью типа System.Windows.Forms. StatusBar) предлагается с момента появления платформы .NET, в .NET 2.0 вместо простого элемента StatusBar предлагается использовать новый тип StatusStrip. Подобно обычной строке состояния, StatusStrip может состоять из любого числа панелей, содержащих текстовые/графические данные, предоставленные типом ToolStripStatus. Однако StatusStrip может содержать и дополнительные элементы, например, следующего вида.

• ToolStripProgressBar – встроенный индикатор выполнения (хода задания).

• ToolStripDropDownButton – встроенная кнопка, отображающая при щелчке на ней раскрывающийся список вариантов выбора.

• ToolStripSplitButton – подобен ToolStripDropDownButton, но отображает элементы раскрывающегося списка только тогда, когда пользователь щелкает непосредственно в области раскрывающегося списка. ToolStripSplitButton предлагает также поведение, аналогичное обычной кнопке, и поэтому может поддерживать обработку события Click.

Для примера мы построим новый объект MainWindow, в котором поддерживается простое меню (Файл>Выход и Справка>О программе) и StatusStrip. Левая панель строки состояния будет использоваться для отображения строковых данных, соответствующих выбранному в настоящий момент элементу меню (например, при выборе пользователем элемента Выход в строке будет отображаться "Выход из приложения").

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

Рис. 19.16. Приложение StatusStrip

Создайте новый проект приложения Windows Forms с именем StatusStripApp. Разместите элемент управления MenuStrip в окне проектирования формы и создайте два пункта меню (Файл>Выход и Справка>О программе). После этого задайте обработку событий Click (щелчок) и MouseHover (задержка указателя мыши) для каждого из дочерних элементов меню (Выход и О программе) с помощью окна свойств.

Реализация обработчика событий Click для элемента Файл>Выход просто завершает работу приложения, а обработчик событий Click для Справка>О программе отображает окно сообщения MessageBox.

private void exitToolStripMenuItem_Click(object sender, EventArgs e) { Application.Exit(); }

private void aboutToolStripMenuItem_Click(object sender, EventArgs e) { MessageBox.Show("My StatusStripApp!"); }

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

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

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

• Добавить нужные элементы в диалоговом окне, появляющемся при выборе ссылки Edit Items (Редактирование элементов) из меню контекстного редактора StatusStrip (см. рис. 19.17).

• Добавить нужные элементы по одному с помощью раскрывающегося меню новых элементов StatusStrip (рис. 19.18).

Мы используем раскрывающееся меню новых элементов. С помощью этого меню добавьте два новых типа ToolStripStatusLabel, назначив им имена toolStripStatusLabelMenuState и toolStripStatusLabelClock, и тип ToolStripDropDownButton с именем toolStripDropDownButtonDateTime. Как и следует ожидать, в результате этого в файл *.Designer.cs будут добавлены новые члены-переменные и соответственно обновлен метод InitializeComponent().

Рис. 19.17. Контекстный редактор StatusStrip

Риc. 19.18. Добавление элементов с помощью раскрывающегося меню новых элементов StatusStrip

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

partial class MainForm {

 private void InitializeComponent() {

  …

  //

  // mainStatusStrip

  //

  this.mainStatusStrip.Items.AddRange(

   new System.Windows.Forms.ToolStripItem[] { this.toolStripStatusLabelMenuState, this.toolStripStatusLabelClock, this.toolStripDropDownButtonDateTime });

  …

 }

 private System.Windows.Forms.StatusStrip mainStatusStrip;

 private System.Windows.Forms.ToolStripStatusLabel toolStripStatusLabelMenuState;

 private System.Windows.Forms.ToolStripStatusLabel toolStripStatusLabelClock;

 private System.Windows.Forms.ToolStripDropDownButton toolStripDropDownButtonDateTime;

 …

}

Теперь в окне проектирования формы выберите ToolStripDropDownButton и добавьте два новых элемента меню День недели и Текущее время, соответственно назначив им имена dayoftheWeekToolStripMenuItem и currentTimeToolStripMenuItem (рис. 19.19).

Рис. 19.19. Добавление пунктов меню для элемента ToolStripDropDownButton

Чтобы настроить панели так, как показано на рис. 19.19, нужно установить подходящие значения для соответствующих свойств в окне свойств Visual Studio 2005. В табл. 19.12 для элементов StatusStrip предлагаются описания свойств, которые нужно установить, и событий, которые нужно обработать (вы, конечно, можете настроить панели так, как сочтете необходимым).

Значение свойства Image члена toolStripDropDownButtonDateTime может указывать на любой файл с изображением, размещенный на вашей машине (при этом, конечно, следует учитывать то, что слишком большие файлы изображений могут порождать проблемы). Для нашего примера вы можете использовать файл happyDude.bmp, предлагаемый вместе с загружаемым исходным кодом для этой книги (посетите раздел загрузки Web-узла Apress, размещенный по адресу http://www.apress.com).

Таблица 19.12. Конфигурация панелей StatusStrip

Итак, проектирование нашего графического интерфейса пользователя завершено. Но, чтобы реализовать оставшиеся обработчики событий, мы с вами должны выяснить роль компонента Timer (таймер).

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

Первым шагом на пути к достижению этой цели является добавление в форму члена-переменной Timer – компонента, вызывающего некоторый метод (указанный с помощью обработчика события Tick) через заданный интервал времени (указанный с помощью свойства Interval).

Перетащите компонент Timer в окно проектирования формы и переименуйте его в timerDateTimeUpdate. Используя окно свойств, установите значение свойства Interval равным 1000 (это значение в миллисекундах), а значение свойства Enabled – равным true (истина). Наконец, обработайте событие Tick. Перед реализацией обработчика событий Tick определите в проекте новый тип перечня с именем DateTimeFormat. Этот перечень будет использоваться для выяснения того, что должен отображать второй элемент ToolStripStatusLabel – текущее время или текущую дату.

enum DateTimeFormat {

 ShowClock,

 ShowDay

}

Построив перечень, обновите MainWindow так, как предлагается ниже.

public partial class MainWindow: Form {

 // Какой формат отображать?

 DateTimeFormat dtFormat = DateTimeFormat.ShowClock;

 …

 private void timerDateTimeUpdate_Tick(object sender, EventArgs e) {

  string panelInfo = "";

  // Создание текущего формата.

  if (dtFormat == DateTimeFormat.ShowClock) panelInfo = DateTime.Now.ToLongTimeString();

  else panelInfo = DateTime.Now.ToLongDateString();

  // Установка текста для панели.

  toolStripStatusLabelClock.Text = panelInfo;

 }

}

Обратите внимание на то, что обработчик события Timer использует тип DateTime. Здесь вы просто читаете текущее время или дату системы, используя свойство Now, и устанавливаете соответствующее значение для свойства Text члена-переменной toolStripStatusLabelClock.

В этот момент обработчик событий Tick должен отобразить в панели toolStripStatusLabelClock текущее время, если значением по умолчанию члена-переменной DateTimeFormat является DateTimeFormat.ShowClock. Чтобы позволить пользователю переключаться между отображением даты и времени, обновите MainWindow так, как предлагается ниже (заметьте, что здесь также указано, какой из двух пунктов меню в ToolStripDropDownButton должен при этом отмечаться).

public partial class MainWindow: Form {

 // Какой формат отображать?

 DateTimeFormat dtFormat = DateTimeFormat.ShowClock;

 // Указывает отмеченный элемент.

 private ToolStripMenuItem currentCheckedItem;

 public MainWindow() {

  InitializeComponent();

  // Эти свойства можно также установить

  // в окне Properties.

  Text = "Пример StatusStrip";

  CenterToScreen();

  BackColor = Color.CadetBlue;

  currentCheckedItem = currentTimeToolStripMenuItem;

  currentCheckedItem.Checked = true;

 }

 …

 private void currentTimeToolStripMenuItem_Click(object sender, EventArgs e) {

  // Установка отметки и формата времени для панели.

  currentCheckedItem.Checked = false;

  dtFormat = DateTimeFormat.ShowClock;

  currentCheckedItem = currentTimeToolStripMenuItem;

  currentCheckedItem.Checked = true;

 }

 private void dayoftheWeekToolStripMenuItem_Click(object Sender, EventArgs e) {

  // Установка отметки и формата даты для панели.

  currentCheckedItem.Checked = false;

  dtFormat = DateTimeFormat.ShowDay;

  currentCheckedItem = dayoftheWeekToolStripMenuItem;

  currentCheckedIteim.Checked = true;

 }

}

Наконец, нужно настроить первую панель так. чтобы она содержала текст подсказки для выбранного пользователем элемента меню. Вы знаете, что большинство приложений отображает в левой части строки состояния поясняющую информацию (например, "Выход из приложения"), соответствующую выбранному конечным пользователем пункту меню. Если вы обработали события MouseHover для всех элементов меню нижнего уровня в MenuStrip и ToolStripDropDownButton, то остается только присвоить подходящее значение свойству Text для члена-переменной toolStripStatusLabelMenuState, например:

private void exitToolStripMenuItem_MouseHover(object sender, EventArgs e) { toolStripStatusLabelMenuState.Text = "Выход из приложения"; }

private void aboutToolStripMenuItem_MouseHover(object sender, EventArgs e) { toolStripStatusLabelMenuState.Text = "Отображение информации о приложении"; }

private void dayioftheWeekToolStripMenuItem_MouseHover(object sender, EventArgs e) { toolStripStatusLabelMenuState.Text = "Отображение текущей даты."; }

private void currentTimeToolStripMenuItem_MouseHover(object sender, EventArgs e) { toolStripStatusLabelMenuState.Text = "Отображение текущего времени."; }

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

Наконец, нужно гарантировать, что при снятии указателя мыши с пункта меню пользователем в первой текстовой панели не останется "старая" подсказка, а будет отображено некоторое "типовое" сообщение (например: "Ожидание действий пользователя"). В текущем своем виде наше приложение оставит в строке текст, соответствующий ранее выбранному пункту меню, что может вызывать, по меньшей мере, недоумение пользователя. Чтобы исправить это, обработайте событие MouseLeave для элементов меню Выход, О программе, День недели и Текущее время. Но вместо генерирования нового обработчика события для каждого элемента, позвольте всем указанным элементам вызывать один метод с именем SetReadyPrompt().

private void SetReadyPrompt(object sender, EventArgs e) { toolStripStatusLabelMenuState.Text = "Ожидание действий пользователя."; }

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

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

Тип ToolStrip в .NET2.0 предлагается использовать вместо типа ToolBar, предлагавшегося в рамках .NET 1.x и теперь считающегося устаревшим. Вы знаете, что панели инструментов обычно обеспечивают альтернативный способ активизации соответствующих пунктов меню. При щелчке пользователя на кнопке Сохранить, результат будет тем же, что и при выборе Файл>Сохранить из меню. Подобно MenuStrip и StatusStrip, тип ToolStrip может содержать множество разных элементов панели инструментов (возможности использования некоторых из них вы уже видели в предыдущих примерах).

• ToolStripButton

• ToolStripLabel

• ToolStripSplitButton

• ToplStripDropDownButton

• ToolStripSeparator

• ToolStripComboBox

• ToolStripTextBox

• ToolStripProgressBar

Подобно другим элементам управления Windows Forms, ToolStrip поддерживает встроенный редактор, который позволяет быстро добавить стандартные типы кнопок (File, Exit, Copy, Paste и т.д.), изменить поведение стыковки и встроить ToolStrip в ToolStripContainer (подробнее об этом чуть позже). Возможности поддержки ToolStrip в режиме проектирования демонстрируются на рис. 19.20.

Рис. 19.20. Возможности режима проектирования для ToolStrip

Подобно MenuStrip и StatusStrip, индивидуальные элементы управления ToolStrip добавляются во внутреннюю коллекцию ToolStrip с помощью свойства Items (элементы). Если щелкнуть на ссылке Insert Standard Items (Вставить стандартные элементы) встроенного редактора ToolStrip, то в метод InitializeComponent() будет добавлен массив производных от ToolStripItem типов, представляющих соответствующие элементы.

private void InitializeComponent() {

 …

 // Автоматически генерируемый программный код

 // для подготовки ToolStrip.

 this.toolStrip1.Items.AddRange(new System.Windows.Forms.ToolStripItem[] {

  this.newToolStripButton, this.openToolStripButton,

  this.saveToolStripButton, this.printToolStripButton,