Partilhar via


Considerações de design de interoperação

Esta visão geral explica as diferenças entre os modelos de programação gerenciadas e. Para obter recomendações e estratégias de interoperação de tempo de design, consulte Criando COM componentes de interoperação e Construindo.NET Framework componentes de interoperação.

Todas as chamadas feitas entre código gerenciado e devem negociar os requisitos impostos pelo modelo de programação do respectivo. Modelos de programação gerenciados e são diferentes em vários aspectos. A tabela a seguir mostra as características de cada modelo.

Característica

Modelo não gerenciado

Modelo gerenciada

Detalhes

Modelo de codificação

Baseado em interface

Baseada em objeto

Objetos não gerenciados sempre se comunicar através de interfaces; classes e objetos gerenciados podem passar os dados diretamente, sem implementar interfaces.

Por padrão, a interoperabilidade COM gera uma interface de classe para expor a funcionalidade gerenciada por meio de uma interface COM quando o objeto ou classe não implementa um.

Identidade

GUIDs

Nomes fortes

Identificam um tipo específico de não gerenciado e não fornecem nenhuma informação de local para esse tipo de GUIDs. Nomes de alta segurança consistem em um nome do assembly exclusivo, além de um nome de tipo. Porque o nome do assembly identifica o tipo, você pode reutilizar um nome de tipo entre vários assemblies. Um assembly também apresenta informações sobre o local para um tipo gerenciado, a versão e a chave do publisher. Serviços interoperacionais geram GUIDs e são fortes conforme necessário.

Mecanismo de tratamento de erro

HRESULTs

Exceções

Métodos COM geralmente retornam um HRESULT, indicando que a chamada teve êxito ou falha. Código gerenciado incorpora exceções. Por padrão, a interoperabilidade COM mapas exceções gerenciadas falha HRESULTs.

Estruturas de dados antigo simples (PODS)

Estrutura

Gerenciado estrutura derivada do objeto

Invocação de plataforma não pode ser usado para retornar classes ou estruturas por valor, se elas contiverem um construtor. Em geral, os tipos definidos pelo usuário que contêm elementos de não-PODS devem ser retornados por referência. Os PODS são estruturas de dados que contêm apenas passivas coleções de valores de campo, conforme definido pela ISO/IEC 14882 padrão, "linguagens de programação — C++." Eles não contêm construtores, copiar os operadores de atribuição, destrutores ou membros de dados de não-estático que não são propriamente ditos PODS.

Compatibilidade de tipo

Binário padrão

Padrão de tipo

Tipos variam entre código gerenciado e e entre idiomas.

Definição de tipo

Biblioteca de tipos

Metadados

Se você estiver acostumado a trabalhar com bibliotecas de tipos, você sabe que eles contêm tipos públicos somente. Além disso, uma biblioteca de tipos é opcional. No modelo de programação gerenciada, informações de tipo são obrigatórias para todos os tipos. Serviços interoperacionais fornecem ferramentas que convertem as bibliotecas de tipo aos metadados em assemblies e para tipos de bibliotecas.

Segurança de tipos

Tipo não seguro

Opcionalmente, segurança

Compiladores não-gerenciados não fornecem nenhum tipo de verificação de tipos de ponteiro, tornando o código suscetível a atividades potencialmente nocivas. Em geral, o código gerenciado exige um nível mais alto de confiança. Os programadores podem continuar a usar ponteiros no código gerenciado, embora o código possui restrições devido seu comportamento inseguro. Serviços interoperacionais impedir não confiável, o código gerenciado de acessar o código não gerenciado.

Versionamento

Imutável

Resistente

Interfaces COM são imutáveis. Se você alterar uma interface, você deve renomeá-lo com um novo GUID. Tipos gerenciados podem evoluir, mantendo o mesmo nome.

Algumas características do modelo de programação associou a entidades que você pode exibir, como bibliotecas de tipos e metadados. Alguns você pode passar como argumentos, como, por exemplo, nomes fortes e GUIDs. Outras características são mais conceituais; Você certamente irá considerar seu impacto em seu projeto de aplicativo, mas você não encontrará um mapeamento direto entre os modelos de gerenciada e essas características.

Tópicos relacionados

Título

Descrição

Criando COM componentes de interoperação

Descreve estratégias de interoperação de tempo de design para componentes COM.

Construindo.NET Framework componentes de interoperação

Descreve as estratégias de interoperação de tempo de design para.NET Framework disponíveis.

Interoperação com Código Não Gerenciado

Descreve como usar COM invocação de plataforma e interoperabilidade.

Interoperabilidade de COM avançadas

Descreve os conceitos de interoperabilidade de COM e regras de conversão.

Interop Marshaling

Descreve a interoperabilidade de empacotamento de serviço, sua relação COM o empacotamento e sua função nas comunicações remotas.