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

Regsvcs .NetComponentName [COM+AppName] [TypeLibrary.tlb]

С помощью второго аргумента (COM+AppName) можно определить другое имя для создаваемого приложения COM+, предоставляя второй аргумент командной строки при вызове RegSvcs. Для еще большей гибкости можно определить имя файла библиотеки типов, которая создается при предоставлении третьего аргумента (TypeLibrary.tlb). Желательно всегда предоставлять эти аргументы при вызове RegSvcs, так как более ранние версии этой программы будут молчаливо перезаписывать любые существующие файлы, которые могут иметь такие же имена, как у вновь создаваемых файлов.

Предварительные итоги

Теперь мы знаем, как подготовить сборку .NET для применения вместе со службами COM+. Эта подготовка включает в себя:

□ Снаряжение сборки рекомендованными атрибутами сборки

□ Соединение классов прокси с внутренними "рабочими" классами посредством атрибута ComEmulate

□ Развертывание сборок с помощью sn.exe, al.exe и, возможно, RegSvcs.exe

Имея общую информацию, перейдем к обсуждению использования конкретных служб COM+ из сборок .NET. Начнем с транзакций.

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

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

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

Определение транзакционной поддержки

Ранее при использовании транзакций из служб COM+ можно было увидеть настройку уровня транзакций в окне свойств класса в Snap-In службы компонентов. Эта настройка позволяет задать уровень поддержки транзакций, который службы COM+ будут предоставлять стандартному компоненту COM.

Иначе в .NET уровень поддержки транзакций в сборке можно определить не с помощью графического окна в snap-in службы компонентов, а программным путем с помощью атрибута Transaction, определенного в пространстве имен EnterpriseServices. В примере ниже мы определяем, что следующий класс прокси должен поддерживать транзакции. При заданном значении атрибута компонент будет сконфигурирован для поддержки транзакций, когда он импортируется в службы COM+ с помощью RegSvcs.exe.

[Transaction(TransactionOption.Supported)]

public class ProxyClass:ServicedComponent {

}

Supported является только одним из нескольких значений, которые можно присвоить атрибуту Transaction компонента. Фактически, существует четыре значения, которые представлены в перечислении TransactionOption, являющемся частью пространства имен System.EnterpriseServices.

□ Когда атрибут Transaction класса задан как Disabled, службы COM+ не предоставляют транзакционной поддержки для класса, даже если такая поддержка определена где-то в коде. (Другими словами, вызовы этого класса, сделанные для ContextUtil с целью фиксации или отмены транзакций, игнорируются. Мы познакомимся с ContextUtil в следующем разделе.)

□ Когда атрибут Transaction класса задан как NotSupported, такой класс не вовлекается в транзакции, запускаемые его клиентами, другими словами он не помещается в их контекст. В данной конфигурации объекты этого класса не определяют, будет ли вызываемая транзакция фиксироваться или отменяться.

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

□ Когда атрибут Transaction класса задан как Required, службы COM+ знают, что объекты этого класса могут выполняться только в контексте транзакции. Если такой объект вызывается клиентом, имеющем транзакционный контекст, объект наследует контекст транзакции клиента. Если, однако, объект вызывается клиентом, который не имеет транзакционного контекста, службы COM+ создают контекст для этого объекта.

□ Когда атрибут Transaction класса задан как RequiresNew, службы COM+ создают новую транзакцию для класса каждый раз, когда он вызывается. Даже если клиент объекта уже имеет транзакцию, службы COM+ создают новую транзакцию для серверного объекта. Как можно догадаться, классы, сконфигурированные подобным образом, способны отменить только свои собственные транзакции, а не работу своих клиентов.

На практике большинство разработчиков используют только одну или две из этих настроек. Значение Supported подходит для классов типа класса Settings , которому нужно будет обслуживать классы с транзакциями и без транзакций. Для большинства других транзакционных классов можно справиться, задавая значение Required. Однако все-таки может возникнуть ситуация, где потребуются одно или несколько составных значений, дополнительную информацию можно найти в книге "Professinal Windows DNA Programming" (ISBN 1-861004-45-1) издательства Wrox Press.

Кодирование транзакций с помощью ContextUtil

Модификация класса с помощью атрибута Transaction является только частью того, что необходимо сделать, чтобы подготовить его для участия в транзакции. Надо также определить, как каждый метод в этом классе ведет себя, когда он вызывается как часть транзакции. Это осуществляется с помощью класса ContextUtil из пространства имен System.EnterpriseServices.

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

В качестве примера сделаем краткий обзор фрагмента кода, приведенного ниже.

public bool PlaceOrder(bool CommitTrans) {

 // Попытка работы

 try {

  if (CommitTrans) {

   // Эта транзакция должна быть зафиксирована

   // шаг 1 — увеличить число единиц продукта ID=2 на 10

   IncreaseUnits(2, 10);

   // шаг 2 — сократить запас продукта ID=2 на 10 единиц

   ReduceStock(2, 10);

  } else {

   // Эта транзакция должна быть отменена

   // шаг 1 — увеличить число единиц продукта ID=5 на 5 единиц

   IncreaseUnits(5, 5);

   // шаг 2 - сократить запас продукта ID=5 на 5 единиц

   ReduceStock(5, 5);

  }

  // Если все прошло хорошо, завершить транзакцию.

  ContextUtil.SetComplete();

  return true;

 }

 // Этот код выполняется, если встречается ошибка.

 catch (Exception е) {

  // Отменить работу, которую выполнила эта функция.

  ContextUtil.SetAbort();

  return false;

 }

}

Что здесь происходит?

Мы имеем две транзакции, которые обрабатываются в зависимости от значения CommitTrans. Для любой транзакции PlaceOrder() вызывает два метода, которые оба соединяющиеся с базой данных Northwind, чтобы сделать изменения в таблице Product. Метод ReduceStock() сокращает объем запасов в столбце UnitsInStock, метод IncreaseUnits() увеличивает значение столбца UnitsOnOrder(). Для обоих методов первым параметром является ProductID в строке, которую нужно изменить, второй параметр есть величина, на которую мы хотим изменить соответствующий столбец.

Выполняющаяся транзакция контролируется булевой переменной CommitTrans, передаваемой в PlaceOrder(). Первая транзакция должна быть зафиксирована, так как уровень запаса для ProductID=2 равен 17, следовательно, можно удалить десять элементов и все еще иметь оставшийся запас. Однако вторая транзакция обречена на отказ так как ProductID=5 не имеет запаса элементов и существует ограничение на столбец UnitsInStock, которое не позволяет значению становиться меньше нуля. Это означает, что можно проверить, будет ли транзакция отменяться или нет. Не должно быть никаких проблем с вызовом IncreaseStock(), поэтому можно увидеть, что транзакция была отменена, проверяя значение столбца UnitsOnOrder для ProductID=5.

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