Особенности объектов MBR-типа

Как вы видели, конфигурирование объекта MBV несложно и требует только применения атрибута [Serializable] для того, чтобы позволить возвращать копии объектов типа в домен клиентского приложения. С этого момента все взаимодействие с MBV-типом происходит на стороне клиента. Когда клиент завершает использование MBV-типа, то он становится кандидатом на сборку мусора, и никаких проблем не возникает.

Но для MBR-типов есть несколько возможных вариантов выбора конфигурации. Как уже говорилось, конкретный объект MBR-типа может быть сконфигурирован с учетом времени активизации, состояния и управления жизненным циклом существования. Чтобы представить весь набор возможностей, в следующей таблице представлено отношение WKO- и CAO-типов к рассмотренным особенностям.

1.5. Инсталляция приложения, использующего удаленное взаимодействие

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

• Клиент. Эта сборка (компоновочный блок) представляет собой сущность, заинтересованную в получении доступа к удаленному объекту (такую как приложение Windows Forms или консольное приложение).
• Сервер. Эта сборка представляет собой сущность, принимающая запрос от удаленного клиента и размещающая в себе удаленные объекты.

Что же собой представляет третья сборка? Во многих случаях серверное приложение обычно содержит в себе третью сборку, которая определяет и реализует удаленные объекты. Для удобства назовем ее общей сборкой (general assembly) или общим компоновочным блоком. Это отделение сборки, содержащей удаленные объекты, от сборки хоста сервера довольно важно, поскольку обычно клиентская и серверная сборки устанавливают ссылки на общую сборку, чтобы получить метаданные типов, допускающих удаленный доступ.

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

• Сконструировать удаленные объекты на основе интерфейсов. В этом случае клиент может устанавливать ссылку на двоичный блок.NET, содержащий только определения соответствующих интерфейсов и ничего более.
• Использовать приложение командной строки soapsuds.exe. С помощью этого приложения можно сгенерировать сборку, содержащую только метаданные удаленных типов.
• Вручную построить сборку, содержащую только метаданные удаленных типов.

Чтобы не усложнять, мы будем строить и развертывать общие сборки, содержащие необходимые метаданные вместе с реализациями на языке MCIL.