Recientemente, me encontré con un escenario de aplicación de este tipo. Una determinada empresa ha estado utilizando un sistema desarrollado por PowerBuilder durante muchos años. A medida que la empresa se desarrolló, decidió convertir el antiguo sistema de información de C/S a la popular arquitectura B/S. surgió el problema: Algunos sistemas originales tienen una gran cantidad de entrada de datos, impresión precisa de informes y otras funciones, y los usuarios están muy acostumbrados a este tipo de operación. Se espera que el nuevo sistema pueda conservar esta característica fácil de usar. del sistema original.
Me dolió la cabeza tan pronto como escuché esta pregunta. PB tiene muchos controles potentes. Es demasiado difícil moverlos al navegador y usar páginas web para simularlos.
1. ¿Por qué es difícil para B/S proporcionar una buena experiencia de interacción con el usuario?
Aquí hay varios problemas importantes:
(1) El protocolo HTTP sin estado
puede intercambiar información directamente entre formularios de Windows a través de la memoria, pero como base de B/S. arquitectura de comunicación El protocolo HTTP no tiene estado.
Si el navegador se considera un huésped y el servidor web se considera un hotel, bajo la gestión del protocolo HTTP, se producirá esta situación: no importa cuántas veces visite un huésped, el servidor web lo considerará como el primero. visitante del tiempo. De esta manera, los huéspedes deberán traer consigo sus documentos de identidad en cada ocasión para que el personal del hotel "verifique su identidad".
La falta de estado del protocolo HTTP conduce al "desprecio" del servidor web. Aunque esto puede aumentar el rendimiento del servidor web, trae problemas al desarrollo de los sistemas de aplicaciones. Debido a que a menudo hay muchos procesos de procesamiento de negocios en los sistemas de aplicaciones, que son inherentemente flujos de información, es decir, los datos originales ingresan por un extremo y deberían haber pasado por un cierto procesamiento cuando salen por el otro extremo. ¿Se perderá la información en todo el proceso comercial? Por lo tanto, compartir información entre solicitudes HTTP se convierte en un asunto problemático. Este es el problema de "retención de estado" de las solicitudes HTTP. Todo sistema B/S debe resolver este problema. Microsoft pensó en algunos "trucos torcidos", como hacer un uso completo de los campos ocultos en las páginas web HTML y luego hacer algunos trucos en el servidor web, por lo que ASP.NET tiene un conjunto de tecnologías para mantener el estado entre cada solicitud HTTP: Sesión, Cookie, ViewState, Perfil, Aplicación.
Sin embargo, el problema no está completamente resuelto. Por ejemplo, en el cuadro de diálogo común en el sistema C/S que recopila información de entrada del usuario, hay intercambio de información entre el formulario principal y el cuadro de diálogo (se divide en dos tipos: modal y no modal. El cuadro de diálogo anterior es no cerrado. El formulario principal no se puede activar). Bajo la arquitectura B/S, dado que cada solicitud del navegador es independiente, se debe implementar un intercambio de información directo similar a un cuadro de diálogo modal entre dos ventanas de navegador independientes. saber qué hacer.
AJAX utiliza el siguiente método para "simular" un formulario modal: "combinar" el formulario principal y el cuadro de diálogo en uno solo. El cuadro de diálogo es un elemento div en HTML, que generalmente se oculta y se muestra cuando es necesario. El kit de herramientas de control AJAX de Microsoft incluso tiene un control diseñado para esta funcionalidad. Existen innumerables trucos como este en el desarrollo de B/S.
Se puede ver que muchas funciones que se pueden implementar fácilmente en C/S son muy difíciles de implementar en B/S.
(2) Entorno operativo especial:
el entorno operativo frontal del sistema B/S del navegador es el navegador, lo que conlleva muchas restricciones. No puede hacer muchas cosas, como acceder directamente al hardware (como impresoras) y no puede completarlo. uso de los recursos de hardware. Por ejemplo, las computadoras nuevas de hoy son todas de doble núcleo. ¿Puede usar JavaScript y HTML directamente para escribir un programa de subprocesos múltiples para aprovechar al máximo estos dos "núcleos Pentium"?
El sistema C/S se ejecuta directamente en el sistema operativo (operativo). sistema) Arriba, puede llamar a todas las funciones proporcionadas por el sistema operativo, y esta limitación no existe.
(3) El vergonzoso lenguaje de programación del cliente web: JavaScript,
un programa C/S tradicional, puede utilizar una gran cantidad de diversos lenguajes de desarrollo, especialmente los principales lenguajes orientados a objetos como C ++, Java y C #, que son Potente y fácil de usar, hay varias herramientas de desarrollo disponibles y son muy maduras.
Por el contrario, JavaScript, el lenguaje de programación más utilizado en el front-end B/S, no sólo no gusta, sino que incluso es "odiado" por muchos programadores, que consideran "programar con JavaScript" como una tarea ardua.
Echemos un vistazo a las dos principales deficiencias de JavaScript.
En primer lugar, falta un modelo de programación claro y unificado.
Aunque JavaScript tiene Java en su nombre y usa una sintaxis similar, no tiene nada que ver con Java real. Por desgracia, ella es un patito feo. Siempre quiere convertirse en cisne, pero no espera que los demás no crean en su idea.
JavaScript usa muchos objetos, pero no es convincente decir que está orientado a objetos (la unidad básica de la programación orientada a objetos es una clase, por ejemplo, no tiene la palabra clave clase similar a los lenguajes orientados a objetos convencionales). como C#, hay funciones una por una en todas partes, lo que hace que sea difícil definir claramente todo el código en forma de clases al mismo tiempo, no está estructurado (la unidad básica de la programación estructurada es una función; ), porque el navegador utiliza una secuencia al analizar documentos HTML. Esto lleva a que parte del código JavaScript se coloque fuera de la función y se ejecute directamente al analizar el documento HTML, mientras que la otra parte del código colocado en la función se ejecuta principalmente en un evento. -De manera impulsada, lo que genera problemas complejos. El flujo de ejecución del programa es mucho menos conciso que el uso unificado de llamadas a funciones en la programación puramente estructurada.
Desde este punto de vista, JavaScript tiene las características de métodos de programación estructurados y no estructurados orientados a objetos, pero no es ni pescado ni ave. No tiene un modelo de programación claro y unificado. Estructura y fácil mantenimiento. Hubo mucha confusión.
En segundo lugar, otro defecto de JavaScript es el entorno de ejecución del navegador.
Por razones históricas, diferentes navegadores, e incluso diferentes versiones del mismo navegador, tienen modelos de programación más o menos diferentes. Por lo tanto, debemos escribir código para detectar el tipo de navegador. IE, y escribí otro conjunto para Firefox. Esto es realmente una molestia.
Los problemas anteriores son casi los "defectos" "inherentes" del sistema de arquitectura B/S. Las deficiencias innatas se complementan con la crianza y la gente ha ideado muchos trucos para resolver estos problemas. AJAX es la estrella de la esperanza sobre la que todos son optimistas.
2. Estrella de la esperanza: AJAX
En los últimos días, he aprendido sistemáticamente sobre el marco AJAX de Microsoft. Descubrí que la complejidad de este marco superó con creces mi estimación original. Los ingenieros de Microsoft que diseñaron el marco AJAX exploraron profundamente el potencial de varias tecnologías de desarrollo web, lo que compensó en gran medida los problemas planteados anteriormente.
(1) Expansión del lenguaje JavaScript:
Microsoft ha mejorado las características orientadas a objetos de JavaScript al proporcionar una biblioteca AJAX encapsulada, que puede implementar fácilmente funciones como herencia, definición de interfaces, serialización de objetos, activación de eventos, tipos de reflexión, etc., aunque es más pequeño que el real Todavía existe una brecha entre los lenguajes orientados a objetos (como Java/C#), pero poder disfrazar JavaScript "feo" para convertirlo en algo visible se considera extraordinario.
(2) Mejorar significativamente la funcionalidad del código del lado del navegador.
Con el soporte de la biblioteca AJAX y la funcionalidad mejorada de JavaScript, y con el soporte del propio navegador, puede escribir scripts JavaScript en el navegador para realizar fácilmente solicitudes asincrónicas. server, realiza una actualización parcial de la página y puede llamar directamente al servicio web.
(3) Introducción del método de desarrollo basado en componentes (CBD).
El desarrollo basado en componentes (CBD) ha sido durante mucho tiempo el método de desarrollo principal para los sistemas orientados a objetos. Aunque SOA (arquitectura basada en servicios) está actualmente muy publicitada, es necesario. alcanzar la madurez del CBD. Hasta cierto punto, llevará tiempo.
Para JavaScript, y mucho menos para SOA, es muy difícil implementar CBD.
Para implementar CBD, Microsoft ha "realizado mejoras importantes" en JavaScript y ha mejorado muchas funciones. Basado en la biblioteca AJAX de Microsoft, los programadores pueden desarrollar tres tipos de componentes reutilizables: Ninguno_Visual Component (componente invisible, equivalente a un sistema orientado a objetos). de ellos proporcionan funciones públicas), Comportamiento (comportamiento que amplía las funciones de los controles web existentes) y Control (controles web con elementos de interfaz visual).
En particular, las docenas de controles proporcionados en AJAX Control ToolKit básicamente realizan la simulación B/S de la mayoría de las características de la interfaz de usuario C/S y son un modelo para la aplicación de este nuevo modelo de programación.
Las mejoras de Microsoft al modelo de programación JavaScript permiten a los ingenieros de software desarrollar finalmente código de cliente web utilizando métodos de desarrollo CBD. Creo que esto es un progreso.
(4) Capacidades mejoradas del lado del servidor
Para mejorar las capacidades del código del lado del navegador, debe coordinarse a través del lado del servidor. AJAX en sí se basa en el modelo de programación en el que el navegador y el servidor web se apoyan entre sí (el servidor web proporciona servicios de datos y el navegador proporciona objetos XMLHttpRequest para emitir solicitudes asincrónicas al servidor web. Cuando los datos regresan, los programadores pueden escribir código en JavaScript para implementar procesamiento parcial dinámico de páginas web renovar).
A través de la extensión AJAX, Microsoft ha mejorado la funcionalidad del marco ASP.NET del lado del servidor. Y externalice funciones de uso común en controles web simples, como el control central de AJAX ScriptManager, UpdatePanel para definir áreas actualizables de la página y docenas de AJAX Control Toolkit para mejorar los controles ASP.NET Extender existentes (es decir, un control adjunto a. un control existente, cuyo propósito es extender nuevas funciones al control existente).
Con estos controles, desarrollar programas web front-end es similar a diseñar formularios en VB. Ahora no sólo es posible dibujar una interfaz similar a Windows Forms, sino que también mediante el uso de la solicitud asincrónica de AJAX y la tecnología de actualización parcial de la página, y con la cooperación del servidor web, la experiencia del usuario se puede forzar en Windows Forms.
No importa cuántas personas menosprecien a VB, la ola de popularización de la programación visual provocada por VB ha tenido un impacto de gran alcance. El impulso de Microsoft para que la programación JavaScript llegue a este paso también es una tendencia general. Para mejorar la eficiencia del desarrollo web, se debe dar este paso.
Sin embargo, cabe señalar que no importa cuánto se "reponga", después de todo, es "congénitamente deficiente" y todavía es muy difícil para la arquitectura B/S superar a C/S en términos de experiencia de usuario. .
3. El futuro: B/S o C/S, ¿quién está a cargo?
Debido a la simplicidad de gestión y despliegue, la arquitectura B/S se ha convertido en la primera opción para muchos sistemas de información hoy en día. Sin embargo, los usuarios buscan un buen usuario. experiencia En resumen, existen los siguientes requisitos:
(1) Hermosa interfaz. B/S tiene una ventaja en este sentido.
(2) Entrada conveniente. Por ejemplo, muchos usuarios esperan ingresar datos sin usar el mouse o completar datos automáticamente con simples clics. Esto es difícil de implementar bajo una arquitectura B/S y puede resolver este problema hasta cierto punto.
(3) Velocidad del rayo. Para C/S, hay muchas formas de lograr una velocidad de respuesta rápida, pero no es fácil para B/S. Debido a las limitaciones del navegador, los potentes recursos de hardware del cliente están casi inactivos. Además, la velocidad de la red es el cuello de botella de la arquitectura B/S. A menos que el ancho de banda pueda aumentar rápidamente, WWW estará en espera mundial.
Aunque C/S tiene una buena experiencia de usuario, su problema es que es difícil desarrollar un sistema distribuido que abarque todo Internet. Además, dado que es necesario instalar el cliente, las actualizaciones del sistema y la gestión de versiones de los componentes se convierten en un gran problema. Además, a diferencia de B en la arquitectura /S, solo se deben considerar los problemas del lado del servidor. En la arquitectura C/S, debido a que varios usuarios acceden al servidor al mismo tiempo, las llamadas y dependencias entre los componentes son complejas. También se debe tener en cuenta cuando se trata de acceso multiproceso a recursos compartidos, procesamiento de transacciones, etc. En el lado del servidor, el rendimiento es muy limitado. Por lo tanto, C/S se construye principalmente en la red de área local para uso interno de la empresa.
En la actualidad, B/S y C/S básicamente coexisten. Con la aplicación generalizada de tecnologías B/S como AJAX, B/S continúa ganando ventaja, pero es imposible "derrotar completamente a C/S". .
Lo que es más interesante es: ¿Cómo ve una gran empresa como Microsoft las perspectivas de desarrollo de B/S y C/S?
Los desarrolladores comunes como yo no tenemos la oportunidad de hablar directamente con los ejecutivos de Microsoft, pero podemos verlo desde la empresa. Ruta de desarrollo de productos Aquí hay algunas pistas:
Microsoft no parece creer que B/S represente la dirección futura del desarrollo tecnológico. Por el contrario, muchas de sus acciones apuntan a abandonar los navegadores.
En primer lugar, Microsoft ha simplificado el desarrollo y la implementación de C/S y ha lanzado la tecnología Smart Client, de modo que la actualización de los programas cliente de C/S se puede realizar automáticamente sin intervención manual.
En segundo lugar, Microsoft trabajó duro para cerrar la brecha entre B/S y C/S. Al diseñar ASP.NET, abandonó resueltamente ASP, que había logrado buenos resultados, y adoptó directamente un método de programación similar de "control visual + basado en eventos". a VB Incluso las páginas web se llaman "Formularios" - Formularios web.
En tercer lugar, Microsoft puede considerar que AJAX es una tecnología de transición.
Microsoft tardó en tomar medidas sobre AJAX hasta que vio la rápida popularidad de AJAX debido a la aplicación exitosa de la tecnología AJAX por parte de Google y otras empresas para mejorar la experiencia del usuario web. Luego tomó medidas y agregó extensiones AJAX a ASP.NET. Obviamente, todo el proceso no fue agresivo y no se invirtieron muchos recursos. Esto fue completamente diferente de cuando Microsoft y Netscape lanzaron una guerra de navegadores. Sin embargo, el hecho de que haya incorporado la extensión AJAX como configuración estándar en VS2008 y haya integrado directamente la función de depuración de JavaScript en el IDE muestra que Microsoft todavía se enfrenta a la realidad y reconoce que AJAX tiene una posición importante y un gran potencial de desarrollo.
De hecho, analizo que la ambición de Microsoft es "unificar el mundo", abandonar el navegador y unificar completamente B/S y C/S.
Esto se ve claramente en .NET 3.0/3.5.
En primer lugar, Microsoft utilizó WCF para unificar DCOM, .NET Remoting y otras tecnologías utilizadas principalmente para C/S, integrando muchas características de desarrollo empresarial originalmente ubicadas en COM+, junto con la tecnología de servicios web utilizada principalmente para arquitectura B/S, para unificar Resumen y encapsularlo en un servicio WCF reutilizable. Es obvio que Microsoft quiere cambiar el modelo de desarrollo de sistemas de información de CBD a SOA (es decir, los sistemas futuros ensamblarán servicios en lugar de componentes).
En segundo lugar, Microsoft abandonó el modelo de programación de programas de escritorio de Windows muy maduro (Win32 API + controlador de mensajes/eventos) e introdujo un nuevo marco de programación WPF. Una de las principales innovaciones es la aparición de XAML (Lenguaje de marcado de aplicaciones) que cumple con la especificación XML. . XAML utiliza archivos de texto sin formato en formato XML para describir las interfaces de las aplicaciones.
Podemos comparar fácilmente XAML con XHTML. El navegador analiza el código XHTML y genera una interfaz web visual, mientras que XAML es analizado por la máquina virtual .NET Framework. En Vista, dado que Vista integra directamente .NET Framework 3.0, Vista puede considerarse como un súper navegador. XAML para generar la interfaz de usuario e implementar todas las funciones de su aplicación.
Como resultado, surgió un nuevo modelo de programación, ya sea un sistema B/S o C/S, el método está unificado: leer el código XAML, analizarlo, presentarlo, recibir la entrada del usuario, procesar los datos y mostrar el resultado.
En este modelo de programación, el navegador se convierte en un espectador y ya no es el núcleo de la aplicación cliente.
El nuevo modelo de programación se ejecuta en un sistema operativo con todas las funciones en lugar de un navegador con funcionalidad limitada. La diferencia es enorme. ¿Cómo se pueden comparar las funciones de un navegador que se ejecuta en el sistema operativo con el propio sistema operativo?
Ahora se puede llamar fácilmente al sistema operativo a través de la API (interfaz de programación de aplicaciones) del sistema operativo organizada de forma orientada a objetos. funciones para aprovechar al máximo los recursos de hardware del cliente (por ejemplo, puede desarrollar fácilmente programas multiproceso sobre .NET Framework para "exprimir" las capacidades de trabajo de la CPU de doble núcleo). Todas las interfaces de usuario se describen mediante XAML, que unifica las tecnologías de capa de interfaz de B/S y C/S.
El entorno de ejecución más adecuado para WPF es el sistema operativo Vista. Un subconjunto de sus funciones, ahora llamado Silverlight, se implementa como un complemento del navegador, lo que permite que los programas WPF se ejecuten en navegadores tradicionales. Dado que tanto Silverlight como Vista pueden analizar XAML por sí mismos, ahora puede usar XAML para escribir solo un conjunto de código de interfaz, que es aplicable tanto a B/S como a C/S y obtiene la misma experiencia de usuario.
Debido a algunas deficiencias inherentes de B/S y AJAX, si el sistema B/S mejorado por AJAX se compara con un bailarín, entonces en realidad es un bailarín bailando con grilletes, y la idea de Microsoft es, en lugar de intentar reducir constantemente el peso. De este grillete, ¿por qué no simplemente abandonar este grillete?
El lanzamiento de WPF y WCF por parte de Microsoft es un intento de ese tipo.
Cabe decir que la estrategia de desarrollo de Microsoft se basa en el análisis de las ventajas y desventajas de los B/S y C/S existentes. Tiene su carácter científico y también tiene en cuenta sus propios intereses comerciales. Sin embargo, todavía existen muchas dificultades para llevar a cabo esta estrategia, porque incluso siendo poderoso como Microsoft, no puede dominar el mundo. Los oponentes de Microsoft son tan inteligentes como Microsoft y su tecnología avanza con la misma rapidez.
Se puede concluir que debido a la continuidad de las aplicaciones del sistema de información, B/S y C/S coexistirán al mismo tiempo durante un largo período de tiempo (tal vez de tres a cinco años, tal vez de cinco a diez años). Muchas características sobresalientes de B/S prevalecerán en la competencia con C/S, y esta situación no cambiará significativamente. En cuanto a AJAX, como arma pesada en el sistema B/S, aunque es muy eficaz, tiene muchos defectos. Soy cautelosamente optimista sobre su desarrollo futuro. Sin embargo, como desarrollador web, debes comprender y aplicar esta tecnología.
El aspecto que tendrá el panorama futuro y si una determinada tecnología tiene futuro no lo deciden los individuos. Creo que el patrón final de la batalla entre B/S y C/S será el resultado del juego conjunto entre múltiples factores. Los individuos deben mantenerse al día y ajustar sus acciones y estrategias de manera oportuna. Éste es el destino de los desarrolladores de software contemporáneos.