Desarrollamos una aplicación web ASP.Net alojada en una red interna. Actualmente, tenemos algunas páginas ASPX que manejan las solicitudes web desde el lado del cliente e interactúan con nuestros servidores. Estamos comenzando el desarrollo en nuestra próxima versión de aplicación principal, y estamos decidiendo sobre la arquitectura.Servicio web VS. Páginas Aspx: Pros y Contras
¿Cuáles son las diferencias entre usar páginas ASPX para manejar solicitudes http en comparación con el uso de un servicio web completo (que probablemente sería un servicio WCF)?
Al investigar este problema, he encontrado algunas publicaciones relacionadas que han sido moderadamente útiles, véanse here y here. Mi comprensión de algunas de las diferencias clave es la siguiente:
- Las páginas ASPX están limitadas en cuanto al tipo de solicitudes que pueden recibir. Son estrictamente HTTP, mientras que un servicio WCF puede tener múltiples puntos finales para dar servicio a una variedad de protocolos (HTTP, TCP, etc.).
- WCF Services se definen más concretamente debido a ServiceContracts. Esto significa que si un proyecto hace una referencia al servicio, ellos saben exactamente qué esperar en términos de métodos, uso y documentación. Una página ASPX es más que gratuita para todos en términos de métodos contenidos y solicitudes aceptadas.
Sin embargo, en base a estos conceptos, mis problemas son los siguientes:
- La capacidad de soportar diferentes protocolos es una gran característica en términos de futuro impermeabilización y la compatibilidad, pero ¿qué beneficio real estamos viendo si actualmente somos solo usándolo para interactuar vía HTTP?
- En línea con mi argumento anterior, si solo estamos interactuando con el servicio en una web, ¿alguno de esos puntos realmente hace alguna diferencia? A una solicitud http no le importa ninguno de esos detalles más finos o garantías contractuales siempre que el método que llama "simplemente funcione".
¿Hay algo que me falta? ¿Algún beneficio clave para usar un servicio? Personalmente, apoyo la arquitectura del servicio web. Me gusta la idea de tener un sistema flexible y bien definido que pueda respaldar el desarrollo futuro. Lo que básicamente busco para salir de esto es una forma de ir a un compañero de trabajo y decir "Esto debería ser un servicio por razones xyz y podríamos ver una mejora de b c por hacerlo".
Eso es cierto. Se supone que las técnicas de serialización de WCF también funcionan más rápido que un servicio web de asmx, ¿verdad? – yourbuddypal
Meh. Tal vez un poco, pero dudo que el cuello de botella de rendimiento de cualquier servicio web sea la opción de usar asmx en lugar de WCF. Las penalizaciones de rendimiento en la arquitectura del servicio web se deben casi siempre a interfaces de conversación y/o gráficos de objetos/objetos muy grandes. El solo hecho de que esté realizando una llamada remota a un servicio web hace que la diferencia de velocidad entre WCF y asmx sea insignificante en la mayoría de los casos. WCF es más flexible en diseño, que es una razón válida para elegirlo. –
Re: serializadores, DataContractJsonSerializer de WCF es en realidad menos flexible que JavaScriptSerializer de ASMX por defecto. JSS aceptará fechas y enumeraciones como cadenas, pero DCJS no lo hará.Eso es especialmente tedioso/problemático cuando se trata de las fechas. –