Para obtener un poco de perspectiva, hemos estado utilizando formularios web ASP.NET por edades.¿[HTML5 + jQuery] (no ASP.NET) + WCF es una solución válida para una aplicación web de nivel empresarial?
También conocemos los beneficios de MVC sobre los formularios web, sin embargo, se lanza una opción alternativa que consiste en eludir todas esas capas de abstracción y pasar de una página .HTML pura al servicio WCF.
No .ASPX, no .cshtml/.vbhtml, solo archivos .HTML puros para evitar la lógica y la representación del servidor. Esa es la idea sugerida por algunos, y cada vez es más atractiva con HTML5 y sus características. La capacidad de apuntar a más dispositivos teniendo un control total sobre el HTML también es un factor determinante.
Sé que es factible desde un punto de vista técnico, especialmente con jQuery haciendo las cosas mucho más fáciles, pero me preocupa que al tirar toda la abstracción del lado del servidor (código subyacente en formularios web, controlador y vista) vinculante en MVC) terminaremos haciendo más plomería de la cual no tuvimos que preocuparnos previamente.
La cuestión se reduce a:
- ¿Es una preocupación válida, y si es así qué tipo de cañerías podríamos terminar haciendo?
- ¿Qué es exactamente lo que podríamos perder lanzando todo el framework ASP.NET a un lado (desde el lado de la aplicación web) y simplemente confiando en la comunicación directa a nuestro servicio WCF desde páginas HTML puras?
Nota: He utilizado el término 'nivel empresarial' recalcar que esto no es un simple aplicación web con unas pocas páginas en las que la decisión definitiva de la arquitectura subyacente es irrelevante, estamos hablando de gran aplicación culo aquí :)
Editar: para ser más claro, las principales áreas que son de interés para nosotros en este enfoque son:
autenticación y Autor ization -> MVC maneja esto de una manera muy directa con los atributos (p. AuthorizeAttribute), este enfoque "estático" significa que la WCF tendrá que manejar tokens, encriptarlos/descifrarlos y decidir quién puede hacer todo por su cuenta mientras mantiene toda esta información en cada llamada. ¿Es esta la única solución?
Separación de preocupación -> MVC hace claramente que, y lo hace muy bien puede que añadir. Sin embargo, este enfoque te obliga a escribir explícitamente en tu HTML cuál es la llamada a la función WCF. Entonces, no solo su capa de presentación maneja qué dibujar, sino que también tiene incorporada la lógica de qué llamar para obtener sus datos y cómo distribuirlos en la página. Esto puede no ser tan importante, pero en contraste, ViewBag en MVC le brinda la opción de tener sus URL de servicio WCF como una propiedad dinámica, lo que significa que la lógica ahora es parte de su controlador y no su página HTML. Cambiar esa lógica exime la molestia de pasar por páginas HTML por completo.
Encuadernación & Validación -> He puesto estos dos en la misma cesta, porque en última instancia, una vez que el servicio WCF responde con un objeto JSON que contiene toda la información de mi página necesita para funcionar (incluyendo las reglas de validación) alguien va tiene que unirlo a esos controles inactivos.
Espero que la idea sea lo suficientemente clara, y gracias de antemano.
Es cierto que la abstracción ahora reside en el WCF. En cuanto a la nueva API web, ha estado bajo nuestro radar desde hace un tiempo y es una herramienta muy buena para esta solución. No estamos tan preocupados por el todo "cómo comunicarnos con WCF y con qué", sino más como "¿De qué tenemos que preocuparnos ahora que estamos escribiendo páginas estáticas?" Algunas preocupaciones: implican seguridad, como autorización y autenticación. – Alucardz
... validación, gestión de sesión, posible localización, etc. ... No estoy diciendo que esto no sea factible, por supuesto que WCF puede manejarlo perfectamente bien, pero al hacerlo no estamos "reinventando" la rueda "por así decirlo? – Alucardz
"Probablemente el único inconveniente es que para cada página habrá al menos dos recorridos de ida y vuelta", no es un problema si toda la interacción del usuario estándar está anidada en una sola página. –