Consideraciones de diseño para interoperaciones

En esta información general se explican las diferencias entre los modelos de programación administrado y no administrado. Para conocer las recomendaciones y estrategias de interoperación en tiempo de diseño, vea Generar componentes COM para la interoperación y Generar componentes de .NET Framework para interoperaciones.

Todas las llamadas realizadas entre código administrado y no administrado deben negociar los requisitos impuestos por el modelo de programación respectivo. Los modelos de programación administrado y no administrado son diferentes en numerosos aspectos. En la siguiente tabla se muestran las características que definen cada modelo.

Característica	Modelo no administrado	Modelo administrado	Detalles
Modelo de codificación	Basado en interfaces	Basado en objetos	Los objetos no administrados siempre se comunican a través de interfaces; las clases y los objetos administrados pueden pasar datos directamente sin implementar interfaces. De manera predeterminada, la interoperabilidad COM genera una interfaz de clase para exponer funcionalidad administrada mediante una interfaz a COM cuando el objeto o la clase no implementa ninguna.
Identidad	GUID	Nombres seguros	Los GUID identifican un tipo administrado específico y no proporcionan información de ubicación para dicho tipo. Los nombres seguros constan de un nombre de ensamblado único además de un nombre de tipo. Como el nombre de ensamblado identifica de forma única el tipo, puede reutilizar un nombre de tipo en varios ensamblados. Un ensamblado también proporciona información de clave, versión y ubicación a un tipo administrado. Los servicios de interoperación generan GUID y tienen nombres seguros.
Mecanismo de control de errores	Valores HRESULT	Excepciones	Los métodos COM suelen devolver un valor HRESULT, que indica que la llamada se realizó correctamente o produjo un error. El código administrado incorpora excepciones. De manera predeterminada, la interoperabilidad COM asigna las excepciones administradas a valores HRESULT de error.
PODS (Plain old data structure)	Estructura	Estructura administrada derivada del objeto	La invocación de plataforma no se puede utilizar para devolver estructuras o clases por valor cuando contienen un constructor. En general, los tipos definidos por el usuario que contienen elementos que no son PODS deben devolverse por referencia. Las PODS son estructuras de datos que sólo contienen colecciones pasivas de valores de campo, tal y como se definió en la norma ISO/IEC 14882 "Programming Languages — C++". No contienen constructores, operadores de asignación de copia, destructores ni miembros de datos no estáticos que no sean PODS.
Compatibilidad de tipos	Estándar binario	Estándar de tipo	Los tipos varían entre el código administrado y no administrado, y también entre los lenguajes.
Definiciones de tipo	Biblioteca de tipos	Metadatos	Si está acostumbrado a trabajar con bibliotecas de tipos, sabe que sólo contienen tipos públicos. Además, una biblioteca de tipos es opcional. En el modelo de programación administrado, la información de tipos es obligatoria para todos los tipos. Los servicios de interoperación proporcionan herramientas que convierten las bibliotecas de tipos en metadatos en los ensamblados y los metadatos en bibliotecas de tipos.
Seguridad de tipos	Sin seguridad de tipos	Con seguridad de forma opcional	Los compiladores no administrados no proporcionan comprobación de tipos para los tipos de puntero, lo que hace al código susceptible de posibles actividades peligrosas. En general, el código administrado requiere un nivel de confianza superior. Los programadores pueden seguir utilizando punteros en el código administrado, aunque el código tiene restricciones debido a la falta de seguridad. Los servicios de interoperación impiden que el código administrado que no es de confianza tenga acceso al código no administrado.
Control de versiones	Inmutable	Resiliente	Las interfaces COM son inmutables. Si cambia una interfaz, debe cambiar su nombre con un nuevo GUID. Los tipos administrados pueden evolucionar y, sin embargo, conservar el mismo nombre.

Algunas características del modelo de programación tienen entidades asociadas que puede ver, como las bibliotecas de tipos y los metadatos. Algunas de ellas pueden pasarse como argumentos, como es el caso de los GUID y los nombres seguros. Otras características son más conceptuales; sin duda alguna tendrá en cuenta su impacto en el diseño de su aplicación, pero no encontrará ninguna asignación directa entre los modelos administrado y no administrado para estas características.

Temas relacionados

Título	Descripción
Generar componentes COM para la interoperación	Describe las estrategias de interoperación en tiempo de diseño para los componentes COM.
Generar componentes de .NET Framework para interoperaciones	Describe las estrategias de interoperación en tiempo de diseño para los componentes de .NET Framework.
Interoperar con código no administrado	Describe cómo utilizar la interoperabilidad COM y la invocación de plataformas.
Interoperabilidad COM avanzada	Se describen reglas de conversión y conceptos relacionados con la interoperabilidad COM.
Cálculo de referencias de interoperabilidad	Describe el servicio de cálculo de referencias de interoperabilidad, su relación con el cálculo de referencias COM y su rol en las comunicaciones remotas.