C# для профессионалов. Том II - Симон Робинсон

Атрибут ObjectPooling

Атрибутом с помощью которого необходимо изменить класс, является ObjectPooling. Этот атрибут получает четыре аргумента.

1. Аргумент Enabled является первым. Ему должно быть присвоено значение true.

2. Аргумент MinPoolSize определяет минимальное число экземпляров объектов, которое должны поддерживать службы COM+ в пуле объектов класса.

3. Аргумент MaxPoolSize определяет максимальное число экземпляров объектов, которое должны поддерживать службы COM+ в пуле объектов класса.

4. Аргумент CreationTimeOut определяет период времени, в течение которого службы COM+ должны пытаться получить объект из пула, прежде чем вернуть отказ.

Далее следует пример атрибута ObjectPooling со всеми четырьмя аргументами, примененными к классу. Мы расширим этот фрагмент кода в конце данного раздела.

[ObjectPooling (Enabled=True, MinPoolSize=1, MaxPoolSize=100, CreationTimeout=30)]

public class CreditCard:ServicedComponent {

Интерфейс ServicedComponent

Как можно было заметить, класс в примере выше наследует интерфейс ServicedComponent. Все классы .NET, которые используют пулы объектов, должны реализовывать этот интерфейс. ServicedComponent содержит три метода для переопределения.

1. Метод CanBePooled() используется клиентами для определения, что может быть создан пул объектов класса.

2. Метод Activate() вызывается службами COM+ на объекте в пуле перед тем, как этот объект передается новому клиенту.

3. Метод Deactivate(), напарник метода Activate(), вызывается службами COM+, когда объект освобождается клиентом, чтобы вернуть его в пул доступных объектов.

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

[ObjectPooling (Enabled=true, MinPoolSize=1, MaxPoolSize=100, CreationTimeout=30)]

public class CreditCard:ServicedComponent {

 // Этот метод будет вызываться службами COM+ для определения,

 // что объект находится в пуле.

 public override bool CanBePooled() {

  return true; // необходимо вернуть логическое "true"

 }

 // Этот метод должен вызываться службами COM+, когда объект

 // передается клиенту.

 public override void Activate() {

  // Код инициализации находится здесь.

 }

 // Этот метод будет вызываться службами COM+, когда

 // объект будет возвращаться в пул.

 public override void Deactivate() {

  // Код завершения находится здесь

 }

 // Этот метод будет вызываться клиентом.

 public void PlaceCharge(int OrderInfo, int UserInfo) {

  // код списания средств с кредитной карты находится здесь

 }

}

Как показывает пример, атрибут ObjectPooling и интерфейс ServicedComponent требуются для того, чтобы класс .NET реализовал пул объектов. Также можно заметить, что в отличие от атрибута Transaction атрибут ObjectPooling применяется непосредственно к "рабочей" сборке .NET, а не к классу прокси, созданному с атрибутом ComEmulate, который был рассмотрен ранее в этой главе.

Использование активизации JIT со сборками .NET

Чтобы сконфигурировать класс .NET для активизации JIT, нужно просто изменить класс с помощью атрибута JustInTimeActivation, задав булево значение true. В данном случае класс CreditCard из предыдущего примера модифицируется для активизации JIT.

[JustInTimeActivation(true)]

public class CreditCard: ServicedComponent {

 // Этот метод будет вызываться клиентом.

 public void PlaceCharge(OrderInfo objOrderInfo, UserInfo objUserInfo) {

  // Код для снятия средств с кредитной карты находится здесь

 }

}

Заключение

Прежде чем начинать разработку следующего проекта развития предприятия, познакомьтесь со службами COM+. Упомянутая ранее книга "The Professional Windows DNA" издательства WroxPress является хорошим началом. При правильном использовании службы COM+ дают изобилие функциональности, что потребовало бы немало времени для воспроизведения и еще больше для полной отладки. Более того, подходы, которые службы COM+ используют для поддержки транзакций, сохранения ресурсов и межпроцессной коммуникации являются в некоторой степени базовыми, после изучения их можно будет применять к большому спектру разнообразных проблем. 

Глава 21

Графические возможности GDI+

Это вторая из двух глав в книге, описывающая элементы взаимодействия непосредственно с пользователем, т.е. вывод информации на экран и прием пользовательского ввода с помощью мыши или клавиатуры. В главе 9 мы рассматривали формы Windows и узнали, как выводить диалоговое окно или окна SDI и MDI и как разместить в них различные элементы управления, такие как кнопки, текстовые поля и поля списков. Основное внимание было уделено использованию элементов управления на основе их способности взять на себя полную ответственность за собственное изображение на устройстве вывода. Необходимо только задать свойства элемента управления и добавить методы обработки событий. Стандартные элементы управления — очень мощные, можно получить сложный интерфейс пользователя, используя только их. На самом деле они сами по себе вполне достаточны для полного интерфейса при работе со многими приложениями, в частности диалогового типа или с интерфейсом пользователя типа проводника.

Однако существуют ситуации, в которых простые элементы управления не дают гибкости, требуемой в интерфейсе пользователя. Иногда необходимо ввести текст заданным шрифтом в точной позиции окна или нарисовать изображения, не используя элемент управления "графическая кнопка", простые контуры или другую графику. Хорошим примером является программа Word for Windows. В верхней части экрана находятся различные кнопки и панели инструментов, которые используются для доступа к различным свойствам Word. Некоторые из меню и кнопок вызывают диалоговые окна или даже списки свойств. Эта часть интерфейса пользователя была рассмотрена в главе 9. Но основная часть экрана в Word for Windows будет совершенно другой. Окно SDI выводит представление документа. Оно имеет текст, аккуратно расположенный в нужных местах и выведенный с использованием множества размеров и шрифтов. В документе может быть выведена любая диаграмма и, если посмотреть на документ компоновки для печати, поля реальных страниц также должны быть выведены. Ничего из этого нельзя сделать с помощью элементов управление, описанных в главе 9. Чтобы изобразить такой вывод, программа Word for Windows должна взять на себя прямую ответственность за сообщение операционной системе, что необходимо вывести и где в его окне SDI. Как это делается, объясняется в данной главе. Здесь будет показано, как рисовать различные элементы, включая:

□ Линии, простые контуры

□ Изображения из растровых и других файлов изображении

□ Текст 

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

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

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

Объектная модель GDI+ концептуально достаточно проста, но все же требуется хорошее понимание описанных ниже принципов того, как Windows организует изображение элементов на экране, чтобы эффективно и рационально использовать GDI+.

Эта глава делится на два основных раздела. Первые две трети главы посвящены концепциям, лежащим в основе GDI+, исследуется, как происходит рисование с упором на теорию. Здесь будет представлено довольно много примеров, почти все из которых являются небольшими приложениями, выводящими специфические жестко закодированные элементы (в основном простые фигуры, такие как прямоугольники и эллипсы). В последней трети главы мы сконцентрируемся на разработке развернутого примера, называемого CapsEditor, который выводит содержимое текстового файла и позволяет пользователям делать некоторые изменения в выводимых данных. Назначение этого примера состоит в демонстрации принципов рисования, применяемых на практике в реальном приложении. Для реального рисования обычно необходим небольшой код — классы GDI+ работают на достаточно высоком уровне, поэтому в большинстве случаев требуется только несколько строк кода для рисования одиночного элемента (например, изображения или фрагмента текста). Но хорошо спроектированное приложение, использующее GDI+, будет выполнять за сценой большую дополнительную работу, т.е. обеспечивать эффективность рисования, и, если потребуется, обновление экрана без каких-либо лишних изображений. (Это важно, так как основная часть работы по рисованию требует от приложения высокой производительности.) Пример CapsEditor показывает, как делать большую часть этого фонового управления.