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

Экземпляры САО-типов, с другой стороны, можно создавать с помощью любого конструктора типа, и они создаются тогда, когда клиент использует ключевое слово 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" /›