Servicios web – WCF vs. ASMX (“Estándar”)

Estoy trabajando en un nuevo proyecto. ¿Hay algún beneficio al ir con un servicio web de WCF a través de un servicio web tradicional antiguo?

Visual Studio ofrece plantillas para ambos. ¿Cuáles son las diferencias? ¿Pros y contras?

¿Qué es un “servicio web normal y antiguo”? ¿Un servicio ASMX, o estás usando WSE también? Los servicios ASMX no son naturalmente interoperables, no son compatibles con las especificaciones WS- * y ASMX es una tecnología que está envejeciendo muy rápidamente. Los servicios WSE (Web Service Enhancements) PUEDEN agregar soporte para WS- * y se pueden hacer para que sean interoperables, pero WCF está destinado a reemplazar a WSE, por lo que debe tomarse el tiempo para aprenderlo. Yo diría que, a menos que su aplicación sea rápida y sucia, obtendrá una flexibilidad inmensa y tendrá un mejor diseño si elige WCF. WCF tiene una curva de aprendizaje más allá de un atributo [WebMethod], pero la curva de aprendizaje es exagerada en mi opinión, y es exponencialmente más poderosa y a prueba de futuro que los servicios heredados de ASMX.

A menos que su línea de tiempo simplemente no pueda tolerar la curva de aprendizaje, usted se haría un gran favor al aprender WCF en lugar de quedarse con los servicios web de ASP.NET. Las aplicaciones solo seguirán distribuyéndose e interconectándose cada vez más, y WCF es el futuro de la informática distribuida en la plataforma de Microsoft.

Aquí hay una comparación entre los dos.

Los profesionales de hacer todo por ti mismo son:

  • Sin curva de aprendizaje
  • Muy flexible

Los profesionales de WCF son:

  • Cuesta menos tiempo a largo plazo
  • Cambie los protocolos sin progtwigción

Una desventaja de WCF: algunos nombres de propiedades estáticas pueden ser bastante largos …

Para resumir: WCF te permite concentrarte en la progtwigción, pero debes aprenderlo primero 😉

Pro para WCF: no necesita un servidor web (es decir, IIS). En realidad no necesitas un sistema operativo de servidor.

Me gusta el hecho de que escribir servicios de WCF facilite la separación de su servicio de la implementación. Puede escribir su servicio y luego alojarlo en IIS, una aplicación de consola o un servicio de Windows; también puede hablar a través de HTTP, TCP neto, etc.

¡Las pruebas unitarias en sus servicios de implante e interacción son más fáciles de hacer!

Si su proyecto está utilizando Framework 4.0, ¿por qué no prueba WebApi, que es fácil de entender y usa la convención sobre la configuración?

Es una excelente forma de crear aplicaciones con interfaces súper rápidas

Tenga en cuenta los videos de inicio de MS, se ha desarrollado a partir de los servicios de datos de WCF.

http://www.asp.net/web-api/overview/getting-started-with-aspnet-web-api

En mi experiencia

WCF

Es absurdamente prolijo trabajar con él, no es del todo compatible con otros productos de microsoft y, por supuesto, no es ampliamente aceptado fuera del mundo de Microsoft.

Pero mi principal problema es que no es estable, tiende a fallar (en alguna situación) y requiere modificarlo antes de poder usarlo.

En lugar

SOAP (también conocido como servicio web estándar), funciona, es fácil de trabajar y es ampliamente compatible (Java-JAX lo acepta sin ninguna modificación).

Agregar autenticación en SOAP podría ser un poco complicado pero no imposible.