Метаданные и удаленный доступ. Конфигурационные файлы удаленного доступа. Программируемые атрибуты.
Для того чтобы запросить объект определенного типа, клиенту должны быть доступны метаданные о типе. В примере программы удаленного доступа, рассмотренной в этой главе, просто делается ссылка на реальную сборку, в которой хранится объект. Однако во многих приложениях доступ клиента к реальной сборке нежелателен, так как тогда ее можно будет декомпилировать в исходный код с помощью отражения (т.е. восстановить структурную схему и алгоритм работы по исходным текстам). Чтобы получить метаданные, необходимые для клиентской программы, нужно ссылаться только на объект, который содержит информацию об интерфейсе, а не детали реализации.
Один из возможных способов сделать это состоит в том, чтобы создать версию объекта, которая содержит методы без реализации. Этот интерфейсный класс можно потом встроить в сборку, которая предоставляется клиенту. Можно запускать исключение System::NotSupportedException в методах, чтобы удостовериться в том, что они никогда не будут по ошибке использованы реальным объектом.
Для Web-служб можно использовать утилиту SOAPSUDS, с помощью которой извлекаются метаданные из службы, а затем сгенерировать сборку с требуемыми метаданными. Далее можно скомпилировать заместитель динамически подключаемой библиотеки (DLL), на который должна ссылаться программа-клиент. Концептуально это эквивалентно первому подходу. Сервер, конечно, ссылается на реальную сборку.
В отличие от модели компонентных объектов Microsoft (COM), здесь нет счетчика ссылок, создания и регистрирования отдельных заместителей и заглушек, согласования интерфейсов, беспокойства относительно глобальных идентификаторов и использования системного реестра. Благодаря метаданным для удаленного доступа к объекту необходимо только, чтобы этот объект был производным от MarshalByRefObject.
Конфигурационные файлы удаленного доступа
Конфигурационные файлы используются, чтобы определить, где будет активизирован объект. Клиент затем использует оператор new (создать) для создания объекта. Большое преимущество использования такого подхода заключается в том, что при изменении места расположения (например, унифицированного указателя информационного ресурса (URL) или канала TCP), либо при замене используемого форматера, не нужно будет перепрограммировать клиент.
Многие классы могут быть сконфигурированы клиентом. Файлы конфигурации клиент загружает с помощью метода RemotingConfiguration::Configure.
Программируемые атрибуты
В главе 5 "Управляемый C++ в .NET Framework" мы ввели концепцию атрибутов, которые уже появлялись в нескольких примерах. В этой главе мы использовали атрибуты Serializable (Преобразуемый в последовательную форму) и Synchronization (Синхронизация), которые предоставляются классами .NET Framework. Каркас .NET Framework делает механизм использования атрибутов полностью расширяемым, позволяя определять собственные произвольные атрибуты, которые могут быть добавлены к метаданным класса.
Эти пользовательские метаданные доступны благодаря механизму отражения и могут быть использованы во время выполнения. Чтобы упростить использование самостоятельно определенных атрибутов, можно объявить базовый класс, который будет вызывать отражающий интерфейс прикладного программирования (API) для получения информации из метаданных.
В примере CustomAttribute иллюстрируется использование самостоятельно созданного атрибута InitialDirectory. InitialDirectory указывает начальный текущий каталог, из которого запускается программа. По умолчанию текущим каталогом является тот, в котором содержится решение, и в нашем случае это каталог С:\01\NetCpp\Chap08\CustomAttribute.