Todo el mundo está diciendo cómo .NET Remoting está siendo reemplazado por WCF, pero me pregunto qué tan preciso es eso. No he visto ninguna palabra oficial de que Remoting se esté desaprobando, y me parece que hay ciertamente escenarios en los que el Remoting tiene más sentido que WCF. Ninguno de los objetos o métodos relacionados con Remoting se ha desaprobado, incluso en la versión 4.0 del marco. También entiendo que System.AddIn en los marcos 3.5 y 4.0 usa Remoting.¿Está realmente desaprobado el .NET Remoting?
¿Alguien tiene alguna palabra oficial en sentido contrario?
En el artículo, Choosing Communication Options in .NET (para la versión 3.0, ya que es la última versión de este artículo), se indica: comunicaciones de dominio
8 de varias aplicaciones
Si tiene que soportar la comunicación entre objetos en diferentes dominios de aplicación dentro del mismo proceso, debe usar .NET remoto.
Ahora, eso, por supuesto, no es preciso, ya que WCF se puede usar para cruzar fronteras de dominios de aplicaciones, pero ¿da la recomendación oficial para ese escenario?
Actualización: envié Clemens Vasters (que estaba en el equipo que posee Remoting y WCF) a esta pregunta:
Clemens, entiendo que estás en el equipo que posee tanto la comunicación remota y WCF, y yo Tengo un par de preguntas que creo que necesito ir a la fuente.
En primer lugar, tengo una pregunta acerca de si la comunicación remota está desapareciendo. Específicamente, tenemos una aplicación bastante grande que utiliza la comunicación remota de forma extensiva para la comunicación en tiempo real entre procesos, y me preguntaba si este uso de la comunicación remota se considera "heredado". Si es así, ¿AppDomain.CreateInstance y sus amigos serán reemplazados por otra cosa?
Esta es su respuesta:
Remoting es parte de .NET Framework y, como tal, no va a desaparecer. COM ha estado en Windows desde Windows NT 3.5/Windows 95 y no se ha ido y tampoco creo que vaya a desaparecer pronto.
Dicho esto, hay una inversión de desarrollo muy mínima en Remoting. WCF es el sucesor de Remoting y suplanta COM/DCOM para código administrado.
Para comunicación en proceso, dominio cruzado El acceso remoto es la forma nativa de comunicación del CLR. Si observa problemas de rendimiento al bombear grandes cantidades de datos o muchos mensajes en poco tiempo, debería considerar seriamente WCF y NetNamedPipeBinding.
Consulte http://stackoverflow.com/questions/1295353/why-am-i-seeing-slower-performance-here-from-wcf-than-remoting para obtener una pregunta acerca de por qué WCF es mucho más lento que Remoting en mi situación específica – Mark
Remoting es intrínseco a.NET, y los detalles del rol que desempeña y cómo funciona se pueden encontrar en * Essential .NET * por Don Box y Chris Sells. Sin embargo, se desmorona cuando las comunicaciones entre componentes no son fiables o lentas, y prácticamente todos los transportes, incluso una LAN gigabit, son poco fiables y lentos en comparación con los mensajes en proceso. Cuando las personas hablan de que WCF es lento, generalmente piensan en servicios web. Los servicios web * son * demasiado lentos si intenta usarlos para las comunicaciones en proceso. Sin embargo, están diseñados para tolerar conexiones lentas y poco confiables, y funcionan bien en estas condiciones. –
@Peter: gracias por la información, pero algunas suposiciones son completamente incorrectas. Primero, esa relación remota es lenta o poco confiable. No es. Es muy rápido y muy confiable (a través de canales confiables, por supuesto). Otra es que los "servicios web" (lo que sea que eso signifique) son lentos. Ellos no están. Por supuesto, cualquier proceso en proceso va a ser mucho más rápido que cualquier cosa en la red, pero de eso no se trata en absoluto esta cuestión ... – Mark