Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

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 можно объединить в следующие большие категории.