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 |
|---|---|
Descreve estratégias de interoperação de tempo de design para componentes COM. |
|
Descreve as estratégias de interoperação de tempo de design para.NET Framework disponíveis. |
|
Descreve como usar COM invocação de plataforma e interoperabilidade. |
|
Descreve os conceitos de interoperabilidade de COM e regras de conversão. |
|
Descreve a interoperabilidade de empacotamento de serviço, sua relação COM o empacotamento e sua função nas comunicações remotas. |