Vengo de un fondo de formularios ASP.NET y he encontrado que la codificación del lado del servidor es muy poderosa en el pasado. Sin embargo, más recientemente, he estado deseando eliminar el código del lado del servidor del front-end y reemplazarlo con HTML / JavaScript puro, que accede a los datos a través de los servicios web JSON. No tengo experiencia real en esto, por lo que me gustaría saber si este es un modelo probado. Además, ¿cuáles son las trampas que lo rodean?
Considero que los controles de usuario de ASP.NET son muy útiles, por lo que me gustaría mantener la teoría detrás de esto almacenando plantillas de marcado en archivos HTML separados en el servidor. Estos serán recuperados y utilizados a través de jQuery AJAX y el complemento de plantillas HTML jQuery respectivamente.
Cualquier aportación será extremadamente apreciada.
PD: Perdón por la pregunta novata, pero ¿es este tipo de arquitectura web lo que se conoce como web-2.0 o estoy completamente fuera de lugar?
fuente
Respuestas:
He usado esta técnica exclusivamente para una aplicación web en la que estamos trabajando. Mi backend está alojado en Google App Engine utilizando el SDK de Java, y mi interfaz utiliza HTML, CSS y JavaScript (con jQuery).
El proyecto es más pequeño con solo yo y un diseñador web, y ambos sentimos que este método nos ha ayudado a trabajar mucho más rápido y a lanzar algo al mercado mucho antes.
Ventaja: trabajar con diseñadores web
La principal ventaja de esta técnica es que el diseñador web, que conoce algo de PHP pero no se considera un programador, puede trabajar sin restricciones en HTML y CSS sin tener que atravesar innumerables líneas de JSP, etiquetas de taglib y otros servidores. Se supone que el marcado que nos han dicho durante años hace que la vida de un desarrollador front-end sea mucho más fácil.
Sin todo el marcado del lado del servidor, hemos sido más ágiles. El diseñador web ha cambiado y revisado directamente su diseño original 3 o 4 veces, con muy pocos cambios de mi parte.
Su comentario para mí fue que sentía que el HTML estaba vivo, ya que podía editarlo e inmediatamente ver los cambios en su máquina con datos dinámicos. Ambos nos hemos beneficiado de esto porque la integración es principalmente automática.
Código del lado del servidor y transferencias HTML / CSS
En proyectos anteriores, tuvo que entregar el HTML y CSS a los desarrolladores de Java que luego tomarían su HTML y CSS y lo reescribirían por completo utilizando la tecnología JSP. Esto llevaría mucho tiempo y, por lo general, daría lugar a diferencias sutiles pero importantes en la representación real de las páginas, así como su validación en el validador W3C.
En general, los dos estamos bastante contentos con esta técnica, y todavía tengo cero páginas JSP o código del lado del servidor en mis páginas HTML.
Errores de la técnica REST / JSON
Quizás los mayores escollos son los que aún no hemos encontrado. Espero tener algunos desacuerdos con los desarrolladores de Java más experimentados a quienes les ha lavado el cerebro lo que la fundación Apache y el equipo de Spring les han dicho sobre cómo las bibliotecas de etiquetas hacen que sea más fácil para los desarrolladores frontend trabajar con el código. Espero que haya una curva de aprendizaje a medida que este proyecto se expande y nos enfrentamos a más desarrolladores que podrían tener que desaprender estas técnicas obsoletas que, en mi experiencia, han hecho que el trabajo de los diseñadores web sea más difícil .
Otro escollo es que el código JavaScript se ha vuelto muy masivo. Esto es más problemático tal vez porque estoy usando esta técnica por primera vez, y porque hemos introducido una pequeña deuda técnica al trabajar hacia una liberación rápida. Quizás elegir un mejor marco habría ayudado a aliviar gran parte del código. En mi opinión, nada de esto ha sido espectacular, y me alienta a seguir usando esta técnica y refinar mis habilidades en esta área.
Ventaja: se pueden construir otras aplicaciones en la plataforma
Por último, debo mencionar una ventaja oculta. Debido a que existe un buen grado de separación entre mis servicios web RESTful de back-end y mi interfaz, también he creado una plataforma que puedo ampliar fácilmente.
Uno de nuestros muchachos de operaciones quería probar una prueba de concepto en otra aplicación, y gracias a mis servicios RESTful, pudimos crear una interfaz completamente diferente para la aplicación para resolver un problema completamente diferente. La prueba de concepto desarrollada rápidamente utilizó su propio HTML, CSS y JavaScript, pero utilizó los servicios RESTful como backend y fuente de datos.
Al final, otro gerente de proyecto vio lo que había hecho, y quedó claro de inmediato que la característica necesitaba ser más que una simple prueba de concepto, por lo que su equipo la implementó.
No puedo enfatizar lo suficiente lo reutilizable que es esta arquitectura, tanto a nivel de aplicación como a nivel de HTML / CSS / JavaScript, y definitivamente te animo a que pruebes esto en tu próximo proyecto.
fuente
Ciertamente es una estrategia viable, pero no es una bala de plata.
Pros :
Contras :
fuente
Definitivamente es posible, y probablemente alentador como mejor práctica. Lo que está proponiendo es dividir la interfaz de usuario de la lógica empresarial para que haya una separación clara de las preocupaciones. Esto es realmente bueno.
Con demasiada frecuencia, los marcos que tratamos de confundir y terminan con un software monolítico en el que la interfaz de usuario, la lógica de negocios y los datos se entrelazan entre sí. Eso hace que sea más difícil de mantener y modificar.
Una vez que divide la aplicación en 2 partes, puede reemplazar la interfaz de usuario por completo con algo más: un programa de escritorio u otra interfaz de usuario para dispositivos móviles en comparación con los navegadores de escritorio.
Los bits difíciles que encontrará al hacer esto es que un poco de código que en teoría debería estar en el servidor se colocaría mejor en el cliente, por ejemplo, la validación es más rápida y más receptiva para que el usuario coloque el código de validación en un formar en el cliente de lo que es presionar el servidor para verificar, por ejemplo, un campo de texto solo contiene caracteres alfanuméricos. Lo mismo a menudo se aplica a los datos y las capas empresariales. Solo tiene que tomar decisiones informadas y prácticas sobre cuándo violar la distinción entre las capas.
fuente
Un inconveniente es la necesidad de duplicar parte de la lógica en JavaScript y ASP.net. Esto podría no ser un gran problema para usted dependiendo de su aplicación. A menudo aparece porque no desea pedirle al servidor que verifique cada pequeña cosa ("¿Se le permite al usuario presionar este botón o seleccionar esta opción en esta situación?") Pero tampoco desea depender en el cliente como el único que realiza la validación ya que el usuario tiene control sobre el cliente.
fuente
Si todavía está utilizando ASP.NET WebForms y desea acelerar sus aplicaciones, esto es lo que debe hacer:
ViewStateen todas las páginas y controles de usuarioNo use controles del lado del servidor
<%: VeiwModel.Title%> en lugar de <asp: Literal id = "Title" runat = "server">
En el backend, anule el método OnInit y realice toda la inicialización allí:
anulación protegida anular OnInit (System.EventArgs e) {CreateViewModel (); base.OnInit (e); }
Comprima todos los archivos .css y .js en 1 usando SquishIt
Finalmente, visite www.porsche.se. ¿No es un sitio web muy rápido?
fuente