Вопросы разработки для взаимодействия

В этом обзоре приводится описание различий между управляемой и неуправляемой моделями программирования. Рекомендации и стратегии взаимодействия во время разработки рассматриваются в разделах Построение COM-компонентов для взаимодействия и Построение компонентов .NET Framework для взаимодействия.

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

Характеристика	Неуправляемая модель	Управляемая модель	Подробные сведения
Модель кодирования	На основе интерфейса	На основе объектов	Неуправляемые объекты всегда взаимодействуют через интерфейс; управляемые объекты и классы могут передавать данные напрямую, без реализации интерфейсов. По умолчанию при COM-взаимодействии создается интерфейс класса для предоставления через интерфейс управляемых функций COM-компонентам, если объект или класс не реализует этих функций.
Удостоверение	Глобальные уникальные идентификаторы (GUID)	Строгие имена	Глобально уникальные идентификаторы (GUID) определяют конкретный неуправляемый тип и не предоставляют сведений о размещении для этого типа. Помимо имени типа строгие имена включают уникальное имя сборки. Поскольку имя сборки однозначно определяет тип, имя типа может повторно использоваться в нескольких сборках. Сборка также вводит в управляемый тип сведения о ключе издателя, версии и размещении. Службы взаимодействия создают идентификаторы GUID и используют при необходимости строгие имена.
Механизм обработки ошибок	Значения HRESULT	Исключения	COM-методы обычно возвращают значение HRESULT, указывающее на удачное или неудачное завершение вызова. Управляемый код включает исключения. По умолчанию COM-взаимодействие отображает управляемые исключения в значения HRESULT при сбоях.
Обычные старые структуры данных (PODS)	Структура	Управляемая структура, производная от объекта	Вызов неуправляемого кода нельзя использовать для возвращения структур или классов по значению, если они содержат конструктор. В общем случае, пользовательские типы, содержащие элементы, не относящиеся к обыкновенным структурам данных, должны возвращаться по ссылке. Обыкновенные структуры данных — это структуры данных, содержащие только пассивные коллекции значений полей, в соответствии со стандартом 14882 ISO/IEC, "Языки программирования — C++". Они не содержат конструкторов, инструкций назначения копий, деструкторов и не являющихся статическими элементов данных, которые сами по себе не являются обыкновенными структурами данных.
Совместимость типов	Двоичный стандарт	Стандарт по типам	Типы различны для управляемого и неуправляемого кода, а также зависят от языка программирования.
Определение типа	Библиотека типов	Metadata	Разработчику, привыкшему работать с библиотеками типов, известно, что они содержат только открытые типы. Кроме того, библиотека типов может быть необязательной. В управляемой модели программирования наличие сведений о типе является обязательным для всех типов. Службы взаимодействия предоставляют средства для преобразования библиотек типов в метаданные сборок и метаданных в библиотеки типов.
Безопасность типов	Защита типов отсутствует	Необязательная защита	Неуправляемые компиляторы не обеспечивают проверку типов указателей, что делает код потенциально подверженным вредным воздействиям. В общем случае управляемый код требует более высокого уровня доверия. Программисты могут продолжать использовать указатели в управляемом коде, хотя на код накладываются ограничения из-за его небезопасного поведения. Службы взаимодействия предотвращают доступ из ненадежного управляемого кода к неуправляемому коду.
Управление версиями	Постоянное	Гибкое	COM-интерфейсы являются неизменными. При изменении интерфейса его необходимо переименовать с помощью нового GUID. Управляемые типы могут развиваться с сохранением для них прежнего имени.

С некоторыми характеристиками моделей программирования связаны объекты, которые может просматривать разработчик, например библиотеки типов и метаданные. Некоторые из них могут передаваться как аргументы, например GUID и строгие имена. Другие характеристики являются более абстрактными: несомненно, можно рассмотреть их влияние на разработку приложения, но для этих характеристик невозможно установить прямое соответствие между управляемой и неуправляемой моделями.

Связанные разделы

Заголовок	Описание
Построение COM-компонентов для взаимодействия	Описываются стратегии взаимодействия во время разработки для COM-компонентов.
Построение компонентов .NET Framework для взаимодействия	Описывает стратегии взаимодействия во время разработки для компонентов .NET Framework.
Взаимодействие с неуправляемым кодом	Описывает способы использования COM-взаимодействия и вызовов неуправляемого кода.
Расширенное COM-взаимодействие	Описывает понятия и правила преобразования для COM-взаимодействия.
Маршалинг взаимодействия	Описывает службу маршалинга взаимодействия, ее связь с маршалингом в модели COM и ее роль в удаленном взаимодействии.