Jquery WCF vs Pagemethods

Question

Estoy en las primeras etapas de desarrollo de un sitio web con Jquery. Me pregunto si usar Pagemethods o la clase de servicio WCF. Vi en una de las respuestas SO que dice usar WCF en todos los requisitos futuros tanto como sea posible. Aprecio mucho si alguien puede explicar cuáles son los factores decisivos y las preocupaciones de seguridad.

Answer 1

Los métodos de página utilizan mucha de la misma tecnología utilizada por los servicios web de ASMX. Esa tecnología está estancada. No se espera que se mejore, y solo se esperan errores críticos. Esa no es una buena base para una pieza de código lista para Producción.

Answer 2

No hay nada de malo con el uso de un método de página o ASMX ScriptService si cumplen con sus requisitos.

WCF definitivamente aporta potencia, flexibilidad y características adicionales a la mesa, pero eso tiene una penalidad de complejidad adicional. Si no tiene la intención de utilizar esas mejoras, entonces solo trae la complejidad.

La gente le dirá que el enfoque de ScriptService es "heredado", basado en un texto de encabezado en un artículo de MSDN, pero que se ha desproporcionado. De hecho, newer versions of those same articles ya no llevan la cláusula de exención de responsabilidad. Soltarlo tenía que haber sido una decisión consciente. Los ASP.NET AJAX y ScriptServices del lado del servidor no van a ir a ningún lado en el futuro previsible.

Si solo está hospedando un punto final de devolución de llamada AJAX dentro del mismo proyecto que la página que lo llamará, realmente no puede vencer a los métodos de página y ScriptServices para facilitar su uso. Nunca he visto un buen argumento para explicar por qué la penalización de complejidad de WCF está justificada en ese escenario, aparte de los argumentos de FUD sobre obsolescencia.

El ScriptService/Page Method's JavaScriptSerializer también deserializa los parámetros de entrada DateTime y enum de forma ligeramente más flexible que DataContractJsonSerializer de WCF, que a menudo es bastante útil.

Answer 3

Hace poco se enfrentó a una decisión similar - aquí está algunas cosas que influyeron fuertemente nuestra decisión:

ASMX y PageMethods que funcionen en el servicio ASP.NET, para que puedan compartir los mismos datos de la sesión como las páginas ASP.NET. Si haces un uso intensivo de la sesión (no abordaré si es una buena práctica o no, esa es una discusión completamente diferente), entonces poder compartirla entre las llamadas de tu página y las llamadas al servicio web puede ser un beneficio significativo. En nuestro caso, en realidad almacenamos cierta información de autorización en la sesión; si optamos por implementar nuestros servicios web como WCF, también necesitaríamos implementar nuestro propio marco de inicio de sesión único entre el servicio web y el servicio ASP.NET. No hay nada de malo en eso, pero es el tiempo de diseño/desarrollo/prueba que quizás no desee invertir.

Si su servicio web está alojado en una dirección/puerto diferente del de su servicio ASP.NET, todas las llamadas desde su página se considerarán scripts de sitios cruzados (XSS) y estarán significativamente limitados por el navegador. Hay soluciones para esto (sobre todo en forma de JSONP), pero esas soluciones también tienen limitaciones; por ejemplo, solo se admiten solicitudes HTTP de tipo GET. Como ASMX/PageMethods se ejecutan dentro del servidor ASP.NET, no se considerarán solicitudes XSS. Por supuesto, si puede garantizar que su servicio WCF siempre se implementará en la misma dirección/puerto que su servidor ASP.NET, tampoco se considerarán XSS; en ese caso, este problema es irrelevante.

Desde el punto de vista del futuro, es probable que WCF vea más atención (parches, mejoras, etc.) de MS que ASMX/PageMethods. Sin embargo, la tecnología NO es completamente a prueba de futuro (no cree que todavía escribamos los servicios de WCF dentro de 10 años, ¿verdad?).Entonces, realmente debe medir su propio nivel de comodidad (o el de sus clientes) con respecto a la posible depreciación futura de ASMX.