2011-01-14 14 views
5

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:

  1. 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.).
  2. 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:

  1. 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?
  2. 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".

Respuesta

4

WCF (y los servicios web antiguos basados ​​en asmx) hacen muchas de las tareas de serialización para usted. Puede devolver objetos a partir de métodos, y el marco serializará esos objetos en el formato XML correcto y proporcionará a los clientes el wsdl para que puedan llamar a los métodos de su servicio web y comprender lo que están obteniendo.

Usted podría hacer esto con una página web (apuesto a que hay un montón de PHP "Servicios Web" por ahí), pero que tendría que hacer todo lo que la plomería a sí mismo.

El tipo de solicitud es WCF-magic. WCF tiene la noción de "puntos finales" que le permiten separar el método de llamar al servicio de lo que hace el servicio. Es simplemente una arquitectura mejor (aunque muy compleja) que separa mejor esas dos preocupaciones.

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. WCF usa el nuevo DataContractSerializer en lugar del método más antiguo empleado en los axms, y supuestamente es un poco más rápido. Sin embargo, creo que tendrías que escalar a una gran cantidad de usuarios para ver una diferencia significativa: sería mejor que buscasras primero interfaces de conversación y consultas de base de datos de bajo rendimiento.

Por supuesto, si tiene dudas, mida primero y luego seleccione áreas específicas de bajo rendimiento.

+0

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

+0

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. –

+0

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. –

0

Los servicios web pueden serializar sus clases a través de proxies, no puede hacer eso con una página aspx (AFAIK).

0

Una forma de hacer esto con las páginas ASP.NET es el método de métodos de página: http://aspalliance.com/1922_PageMethods_In_ASPNET_AJAX.all, que es muy similar a la ruta de servicios web de ASMX. Estoy de acuerdo con todo lo que se ha dicho, pero la pregunta es, ¿necesita un servicio dedicado para entregar datos al mundo exterior, o estos servicios solo sirven para transmitir datos al cliente interno de la aplicación?

Tomé el enfoque del método de página en mi enlace porque la mayoría de los servicios eran para facilitar AJAX dentro de la página, y mantenía el código todo junto. Además, los datos se pueden recuperar a través de JQuery incluso con métodos de página, y admite serialización y generación de proxy.

3

No debe utilizar una página ASPX como un punto final de servicio improvisado, como se ve a menudo en el mundo de PHP. Las solicitudes de páginas ASPX se filtran a través de algunos HttpModules que son sobrecargas innecesarias para puntos finales de servicio simples, y cada solicitud crea una instancia de la clase Page sin ningún motivo.

ASMX sigue siendo una gran opción si todo lo que necesita es un punto final muy simple que responda en XML o JSON.

WCF es muy potente si necesita más flexibilidad y está dispuesto a lidiar con la carga de la configuración.

Otra opción que a menudo se pasa por alto es usar un HttpHandler. Es relativamente simple/fácil juntar un ASHX HttpHandler, que le da un acceso muy "cercano al metal" a la solicitud/respuesta con mucho menos sobrecarga que una página ASPX.

2

Podría estar malinterpretando la pregunta, pero no estoy seguro de que su comparación aquí sea totalmente válida. Está comparando una tecnología de entrega de página y servicio con una sobrecarga relativamente alta (ASPX páginas) con tecnologías de solo servicio puro (WCF y ASMX), ¿verdad? Creo que una comparación de los servicios web ASMX vs. servicios web WCF puede ser más válida, en cuyo caso WCF gana facilmente en la capacidad de configuración, por no hablar de rendimiento: http://msdn.microsoft.com/en-us/library/bb310550.aspx

Véase también WCF vs ASPX webmethods vs ASMX webmethods a una pregunta relacionada

Cuestiones relacionadas