que - modelo de objetos de componentes distribuidos
Futuro del modelo de objetos componentes (7)
Bueno, la razón por la que lo llamaron .NET es porque COM3 fue tomado como un nombre de puerto serie. .NET es el nuevo COM. De .Net Common Language Runtime Unleashed :
El nombre cambia de COM3 a COR a COM + 2.0 ... a NGWS y finalmente a .NET.
El motivo por el que el ensamblaje principal se llama mscorlib es que representaba la Biblioteca de tiempo de ejecución de objetos comunes de Microsoft .
¿Alguien ha escuchado algo acerca de que Microsoft [no] admite COM en futuras versiones de Windows?
Imagino que los ingenieros de Microsoft están atascados con eso (incluso si preferirían desarrollar y soportar solo el framework .NET) simplemente debido a la enorme reacción negativa de su gran base de clientes. Debe haber literalmente miles de millones de líneas de productos basados en COM en la naturaleza. Sé que no estoy deseoso de ser empujado a una migración masiva simplemente porque algún astronauta de la arquitectura de exceso de logros y sabelotodo tiene que demostrar que es el mejor ... (Sheesh, ¿por qué no acaban de empezar el boxeo?) .
Sospecho que solo estoy siendo paranoico, pero ¿alguien puede proporcionar enlaces de autoría (Google no encuentra mucho)? Idealmente, un Libro Blanco de Microsoft que dice "¡COM permanece en Viena, o si no!" calmaría mis nervios en gran medida.
COM sigue siendo LA tecnología para la comunicación entre procesos. Mire la forma en que puede controlar Word, Excel, etc. desde otra aplicación. No hay forma de que .Net pueda reemplazar esto.
COM y .Net sirven diferentes necesidades. Siempre que haya un código nativo, habrá una necesidad de un estándar de componentes binarios, es decir, COM. Incluso si el sistema operativo se reescribió desde cero (que no será, ni debería), sería principalmente un código nativo por razones como el rendimiento y el control de versiones. Necesitarás rápidamente inventar algo como COM, ¿por qué no guardar el que ha sido probado y funciona?
Entonces para resumir:
COM permanecerá porque: 1. Funciona fundamentalmente. 2. Maneja la comunicación entre procesos, a diferencia de la comunicación intermachine. 3. .NET heredó mucho de COM, pero no todo. 4. Incluso los propios Microsoft todavía confían en él.
Y tomo el punto de que todavía hay millones de líneas de FORTRAN y COBOL en sistemas de producción hoy ... porque funcionan fundamentalmente.
Gracias a todos por sus respuestas ... Mods, no duden en limpiar esta respuesta conversacional, pero (en mi humilde opinión) este sitio haría bien en permitir que los carteles den las gracias públicamente a aquellos que se toman el tiempo para responder.
Saludos a todos. Keith.
No hay ninguna declaración oficial de que la compatibilidad con COM se elimine de versiones futuras de Windows. se usa ampliamente a través de las partes internas del sistema operativo. A excepción de la reescritura completa del SO desde cero (que no puedo imaginar en el futuro cercano), es seguro asumir que COM estará allí por un tiempo.
No veo desaparecer el COM en el corto plazo, ya que existe una enorme cantidad de código basado en COM heredado. Por la misma razón, espero ver a Win32 dando vueltas por el futuro previsible. A nadie le importa Windows como una plataforma, se preocupan por su software de aplicación.
COBOL en un S / 360, S / 370, S / 390, zSeries y C / unix siguen siendo plataformas muy utilizadas por la misma razón.
Sé que es fácil pensar que el mundo de Microsoft es solo .NET a partir de ahora, gracias al excelente trabajo realizado por su departamento de marketing, pero Microsoft siempre apoya sus viejas cosas, realmente no tienen otra opción.
Miren MFC, han lanzado nuevos paquetes y RibbonBar solo funciona en MFC (ya que la oficina está desarrollada en él). Claro, comenzarán a escribir más y más .NET code a través del tiempo, y cada vez menos cosas de COM, pero aún así lo soportarán.
Las características de desarrollo de COM en Visual Studio permanecerán en su lugar, cuando se vayan, ese es el momento en que sabes que ya no quieren que lo usemos.
Leí una entrada de blog del gerente de proyecto de Visual Studio donde dijo que habían recibido muchas quejas de los desarrolladores sobre el enfoque en C # recientemente. Estuvo de acuerdo y dijo que la próxima versión de Visual Studio se centraría principalmente en el desarrollo de C ++ no administrado.