Prefacio
En los últimos años, la adaptación múltiple basada en la web de varios sitios ha estado en pleno apogeo, y las soluciones que dependen de diversas tecnologías también se han desarrollado entre las industrias. Como el diseño receptivo basado en la consulta de medios CSS3 nativas del navegador, la solución de "adaptación en la nube" basada en la reorganización inteligente de la nube, etc. Este artículo analiza principalmente soluciones de adaptación multi-terminal basadas en la separación de los extremos frontales y traseros.
Sobre la separación frontal
Con respecto a la solución de separación frontal, existe una explicación muy clara en "Pensamiento y práctica de la separación frontal basada en NodeJS (I)". Introdujimos NodeJ como la capa de representación entre la interfaz del servidor y el navegador. Debido a que la capa NodeJS está completamente separada de los datos y no necesita preocuparse por mucha lógica de negocios, es muy adecuado para el trabajo de adaptación múltiple en esta capa.
Detección de UA
Lo primero que debe resolver en la adaptación múltiple es el problema de detección de UA. Para una solicitud, necesitamos saber el tipo de este dispositivo para generar el contenido correspondiente. Ahora hay una biblioteca de características de agente de usuario muy madura y herramientas de detección compatibles con una gran cantidad de dispositivos en el mercado. Aquí hay una lista compilada por Mozilla. Entre ellos, hay quienes se ejecutan en el lado del navegador y los que se ejecutan en la capa de código del lado del servidor. Algunas herramientas incluso proporcionan módulos Nginx/Apache, que son responsables de analizar la información de UA para cada solicitud.
En realidad recomendamos el último. La solución basada en la separación frontal determina que la sonda UA solo puede ejecutarse en el lado del servidor, pero no es una solución suficientemente amigable si el código de la sonda y la biblioteca de características se acoplan en el código de negocio. Muevemos este comportamiento hacia adelante y lo colgamos en Nginx/Apache. Son responsables de analizar la información de UA para cada solicitud y luego pasarla al código de negocio a través del encabezado HTTP.
Hay varios beneficios al hacer esto:
Nuestro código ya no necesita prestar atención a cómo analiza UA, simplemente elimine la información analizada de la capa superior. Si hay múltiples aplicaciones en el mismo servidor, la información de UA analizada por el mismo NGINX se puede usar juntas, guardando la pérdida de resolución entre diferentes aplicaciones.
Solución de detección de UA basada en Nginx compartida por TMall
El servidor web tengine de Taobao también proporciona un módulo similar NGX_HTP_USER_AGENT_MODULE.
Vale la pena mencionar que al elegir herramientas de detección de UA, se debe considerar la mantenimiento de la biblioteca de características. Debido a que hay más y más tipos de equipos nuevos en el mercado, cada dispositivo tendrá un agente de usuario independiente, por lo que la biblioteca de características debe proporcionar buenas estrategias de actualización y mantenimiento para adaptarse a los equipos cambiantes.
Varias adaptaciones integradas en el modo MVC
Después de obtener la información de UA, debemos considerar si la adaptación terminal se realiza en función de la UA especificada. Incluso en la capa NodeJS, aunque falta la mayor parte de la lógica comercial, todavía dividimos las partes internas en tres modelos: modelo/controlador/vista.
Primero usemos el diagrama anterior para analizar algunas soluciones de adaptación múltiples existentes.
Adaptaciones construidas en el controlador
Esta solución debe ser la forma más simple y grosera de lidiar con ella. Pase la misma URL a la misma capa de control a través del enrutador. La capa de control luego distribuye datos y lógica del modelo a la pantalla correspondiente (VIEA) a través de la información de UA para la representación, y la capa de renderizado proporciona plantillas que se adaptan a varios terminales de acuerdo con las preconventiones.
La ventaja de esta solución es que mantiene la unidad de los datos y las capas de control, y la lógica comercial se puede aplicar a todos los terminales solo una vez. Sin embargo, este escenario solo es adecuado para aplicaciones bajas interactivas, como páginas de pantalla. Una vez que el negocio es más complejo, los controladores de cada terminal pueden tener su propia lógica de procesamiento. Si todavía comparten un controlador, hará que el controlador sea muy hinchado y difícil de mantener, lo que sin duda es una opción incorrecta.
Adaptaciones construidas en el enrutador
Para resolver los problemas anteriores, podemos distinguir dispositivos en el enrutador y distribuirlos a diferentes controladores para diferentes terminales:
Esta es también una de las soluciones más comunes, principalmente manifestada en el uso de un conjunto separado de aplicaciones para diferentes terminales. Por ejemplo, cuando la página de inicio de PC Taobao y la versión WAP de la página de inicio de Taobao, cuando diferentes dispositivos visitan www.taobao.com, el servidor redirigirá a la versión WAP de la página de inicio de Taobao o la versión para PC de Taobao Home Page a través del control del enrutador. Son dos conjuntos de aplicaciones completamente independientes.
Sin embargo, esta solución indudablemente produce el problema de que los datos y parte de la lógica no se pueden compartir. Varios terminales no pueden compartir los mismos datos y la lógica comercial, lo que resulta en mucho trabajo repetitivo y es ineficiente.
Para aliviar este problema, alguien propuso una solución optimizada: en el mismo conjunto de aplicaciones, cada fuente de datos todavía se abstrae en cada modelo y se proporciona a los controladores de diferentes terminales para la combinación:
Esta solución resuelve el problema de que los datos anteriores no se pueden compartir. En el controlador, cada terminal todavía es independiente entre sí, pero puede usar el mismo lote de fuentes de datos juntos. Al menos no es necesario desarrollar interfaces independientes para los tipos de terminales en los datos.
En las dos soluciones basadas en el enrutador anteriores, debido a la independencia del controlador, cada terminal puede implementar diferentes lógicas interactivas para sus propias páginas, lo que garantiza una flexibilidad suficiente para cada terminal en sí, lo cual también es la razón principal por la cual la mayoría de las aplicaciones adoptan esta solución.
Adaptaciones construidas en la capa de vista
Esta es la solución utilizada para las páginas de pedido de Taobao, pero la diferencia es que la página de pedidos coloca la capa de representación general en el lado del navegador, en lugar de la capa NodeJS. Sin embargo, ya sea un navegador o NodeJS, la idea general de diseño sigue siendo la misma:
En esta solución, el enrutador, el controlador y el modelo no necesitan prestar atención a la información del dispositivo, y el juicio del tipo de terminal se deja completamente a la capa de visualización para su procesamiento. El módulo principal en la figura es "Ver fábrica". Después de que el modelo y el controlador pasen los datos y la lógica de representación, usan la fábrica View para obtener componentes específicos de un montón de componentes preestablecidos en función de la información del dispositivo y otros estados (no solo la información de UA, sino también el entorno de red, el área de usuario, etc.) y luego combinarlos en la página final.
Esta solución tiene varias ventajas:
La capa superior no necesita prestar atención a la información del dispositivo (UA). Los videos de múltiples terminales todavía son manejados por la capa View que finalmente muestra la mayor relación. No es solo una adaptación múltiple terminal, sino que además de la información de UA, cada componente de vista también puede determinar qué plantilla genera de acuerdo con el estado del usuario, como ocultar imágenes de forma predeterminada a bajas velocidades de red y pancartas de actividad de producción en áreas designadas. Diferentes plantillas de cada componente de vista pueden decidir si utilizar los mismos datos y la lógica comercial a su propia discreción, proporcionando un método de implementación muy flexible.
Pero es obvio que esta solución también es la más compleja, especialmente cuando se considera algunos escenarios de aplicación interactivos, el enrutador y el controlador pueden no ser tan puros. Especialmente para algunas empresas con una integridad relativamente fuerte, que no se pueden dividir en componentes mismos, esta solución puede no ser aplicable; Y para algunos negocios simples, usar esta arquitectura puede no ser la mejor opción.
Resumir
Las soluciones anteriores se reflejan en una o más partes del modelo MVC. Si una solución no satisface las necesidades en los negocios, se pueden adoptar múltiples soluciones al mismo tiempo. O se puede entender que la complejidad y los atributos interactivos en el negocio determinan para qué solución de adaptación multi terminal para la que el producto es más adecuado.
En comparación con el esquema de diseño receptivo basado en el navegador, debido a que la mayoría de la lógica de detección y representación de terminales se migra al servidor, adaptándose a la capa NodeJS, sin duda, aporta un mejor rendimiento y experiencia del usuario; Además, en comparación con los problemas de calidad de conversión causados por algunos llamados esquemas de "adaptación en la nube", no existirán en el esquema "personalizado" basado en la separación frontal. La solución de adaptación para la separación de los extremos frontales y traseros tiene ventajas naturales en estos aspectos.
Finalmente, para adaptarse a necesidades de adaptación más flexibles y potentes, ¡las soluciones de adaptación basadas en la separación frontal enfrentarán más desafíos!