Читать онлайн «ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание». Страница 166

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

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

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

using System.Runtime.Remoting.Messaging;

…

namespace CarGeneralAsm {

 public class CarProvider: MarshalByRefObject {

  …

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

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

  [OneWay]

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

 }

}

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

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

CarProvider ср = new CarProvider();

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

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

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

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

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

Классы Описание Application Класс, инкапсулирующий средства поддержки Windows Forms, необходимые любому приложению Button, CheckBox, ComboBox, DateTimePicker, ListBox, LinkLabel, MaskedTextBox, MonthCalendar, PictureBox, TreeView Классы, которые (вместе со многими другими классами) определяют различные GUI-элементы. Многие из этих элементов подробно будут рассмотрены в главе 21 FlowLayoutPanel, TableLayoutPanel Платформа .NET 2.0 предлагает целый набор "администраторов оформления", выполняющих автоматическую корректировку размещения элементов управления в форме при изменении ее размеров Form Тип, представляющий главное окно, диалоговое окно или дочернее окно MDI в приложении Windows Forms ColorDialog, OpenFileDialog, SaveFileDialog, FontDialog, PrintPreviewDialog, FolderBrowserDialog Представляют различные диалоговые окна, соответствующие стандартным операциям в рамках GUI Menu, MainMenu, MenuItem, ContextMenu, MenuStrip, ContextMenuStrip Типы, используемые для построения оконных и контекстно-зависимых систем меню. Новые (появившиеся в .NET 2.0) элементы управления MenuStrip и ContextMenuStrip позволяют строить меню, содержащие как традиционные пункты меню, так и другие элементы управления (окна текста, комбинированные окна и т.д.) StatusBar, Splitter, ToolBar, ScrollBar, StatusStrip, ToolStrip Типы, используемые для добавления в форму стандартных элементов управления

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