Estoy en las primeras etapas de desarrollo de un sitio web.utilizando Jquery. Me pregunto si usar Pagemethods o la clase de servicio WCF. Vi en una de las respuestas de 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 los aspectos de seguridad.
Respuestas
1 para la respuesta № 1No hay nada de malo en usar un Método de página o un Servicio de Script ASMX si cumplen con sus requisitos.
Definitivamente, WCF aporta potencia, flexibilidad y características adicionales a la mesa, pero eso conlleva una penalidad de complejidad adicional. Si no pretende utilizar esas mejoras, entonces solamente Aporta la complejidad.
La gente le dirá que el enfoque de ScriptService es "heredado", basado en un poco del texto del encabezado en un artículo de MSDN, pero eso está fuera de proporción. De hecho, Nuevas versiones de esos mismos artículos. Ya no llevan el descargo de responsabilidad. Dejarlo caer tuvo que haber sido una decisión consciente. El lado del servidor ASP.NET AJAX y ScriptServices no van a ninguna parte en el futuro previsible.
Si está alojando un punto final de devolución de llamada AJAXdentro del mismo proyecto que la página que lo llamará, realmente puede "vencer a Page Methods y ScriptServices para facilitar su uso. Nunca he visto un buen argumento que explique por qué la penalización de la complejidad de WCF se justifica en ese escenario, Aparte de los argumentos de FUD sobre la obsolescencia.
El ScriptService / Page Method's JavaScriptSerializer también deserializa DateTime y enumera los parámetros de entrada de manera un poco más flexible que el DataContractJsonSerializer de WCF, que a menudo es bastante útil.
1 para la respuesta № 2
Recientemente enfrenté una decisión similar. Aquí hay algunas cosas que influyeron fuertemente en nuestra decisión:
ASMX y PageMethods se ejecutan dentro de la ASP.NET, para que puedan compartir los mismos datos de sesión que las páginas ASP.NET. Si hace un uso intensivo de la sesión (no diré si esa es una buena práctica o no, es una discusión completamente diferente), entonces poder compartirla entre las llamadas de la página y las llamadas de servicio web puede ser un beneficio significativo. En nuestro caso, en realidad almacenamos cierta información de autorización en la sesión; si decidimos implementar nuestros servicios web como WCF, también tendríamos que rodar nuestro propio marco de inicio de sesión único entre el servicio web y el servicio ASP.NET. eso, pero es tiempo de diseño / desarrollo / prueba que quizás no quiera invertir.
Si su servicio web está alojado en un sitio diferentedirección / puerto que su servicio ASP.NET, entonces todas las llamadas a la misma desde su página se considerarán secuencias de comandos entre sitios (XSS) y estarán significativamente limitadas por el navegador. Existen soluciones para esto (principalmente en forma de JSONP), pero esas soluciones también tienen limitaciones; por ejemplo, solo se admiten solicitudes http de tipo GET. Dado que ASMX / PageMethods se ejecutan dentro del propio servidor ASP.NET, No se considerarán las peticiones 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 serán considerados XSS, en ese caso, este problema es discutible.
Desde un punto de vista de prueba de futuro, es probableque WCF recibirá más atención (parches, mejoras, etc.) de MS que ASMX / PageMethods. Sin embargo, NINGUNA tecnología está completamente preparada para el futuro (no crees que sigamos escribiendo los servicios de WCF dentro de 10 años, ¿verdad?;). Por lo tanto, realmente tiene que medir su propio nivel de comodidad (o sus clientes) con respecto a la posible desaprobación futura de ASMX.
0 para la respuesta № 3
PageMethods utiliza gran parte de la misma tecnología utilizadapor los servicios web de ASMX. Esa tecnología está estancada. No se espera que se mejore y solo se solucionen los errores críticos. Esa no es una buena base para un trozo de código listo para producción.