Préface
Ces dernières années, l'adaptation multi-terminale sur le Web de divers sites a été en plein essor, et des solutions reposant sur diverses technologies ont également été développées entre les industries. Tels que la conception réactive basée sur la requête multimédia CSS3 native du navigateur, la solution "Adaptation cloud" basée sur le réarrangement intelligent cloud, etc. Cet article traite principalement de solutions d'adaptation multi-terminales basées sur la séparation des extrémités avant et arrière.
À propos de la séparation frontale
En ce qui concerne la solution de séparation frontale, il existe une explication très claire dans "la pensée et la pratique de la séparation frontale basée sur les nodejs (i)". Nous avons introduit NodeJS comme couche de rendu entre l'interface du serveur et le navigateur. Étant donné que la couche NodeJS est complètement séparée des données et n'a pas besoin de se soucier de beaucoup de logique commerciale, elle est très adaptée aux travaux d'adaptation multi-terminaux sur cette couche.
Détection UA
La première chose à résoudre dans l'adaptation multi-terminale est le problème de détection de l'UA. Pour une demande terminée, nous devons connaître le type de ce périphérique pour y publier le contenu correspondant. Il existe désormais des outils de fonctions d'agent utilisateur très matures et des outils de détection compatibles avec un grand nombre d'appareils sur le marché. Voici une liste compilée par Mozilla. Parmi eux, il y en a tous les deux fonctionnant du côté du navigateur et ceux qui s'exécutent sur la couche de code côté serveur. Certains outils fournissent même des modules Nginx / Apache, qui sont responsables de l'analyse des informations UA pour chaque demande.
En fait, nous recommandons le dernier. La solution basée sur la séparation frontale détermine que la sonde UA ne peut s'exécuter du côté du serveur, mais ce n'est pas une solution suffisamment conviviale si le code de sonde et la bibliothèque de fonctionnalités sont couplés dans le code commercial. Nous faisons avancer ce comportement et l'accrochons à Nginx / Apache. Ils sont responsables de l'analyse des informations UA pour chaque demande, puis de la transmettre au code commercial via l'en-tête HTTP.
Il y a plusieurs avantages à procéder:
Notre code n'a plus besoin de faire attention à la façon dont UA analyse, il suffit de retirer les informations analysées de la couche supérieure. S'il y a plusieurs applications sur le même serveur, les informations UA analysées par le même Nginx peuvent être utilisées ensemble, enregistrant la perte de résolution entre différentes applications.
Solution de détection UA basée sur Nginx partagée par TMALL
Le serveur Web Tenine de Taobao fournit également un module similaire NGX_HTTP_USER_AGENT_MODULE.
Il convient de mentionner que lors du choix des outils de détection UA, la maintenabilité de la bibliothèque de fonctionnalités doit être prise en compte. Parce qu'il y a de plus en plus de nouveaux types d'équipements sur le marché, chaque appareil aura un agent utilisateur indépendant, de sorte que la bibliothèque de fonctionnalités doit fournir de bonnes stratégies de mise à jour et de maintenance pour s'adapter à l'équipement de l'équipement.
Plusieurs adaptations intégrées au mode MVC
Après avoir obtenu les informations UA, nous devons déterminer si l'adaptation terminale est effectuée en fonction de l'UA spécifié. Même dans la couche NodeJS, bien que la majeure partie de la logique métier manque, nous divisons toujours les internes en trois modèles: modèle / contrôleur / vue.
Utilisons d'abord le diagramme ci-dessus pour analyser certaines solutions d'adaptation multi-terminales existantes.
Adaptations construites sur le contrôleur
Cette solution devrait être la façon la plus simple et la plus grossière de y faire face. Passez la même URL à la même couche de contrôle à travers le routeur. La couche de contrôle distribue ensuite les données et le modèle de la logique à l'affichage (vue) correspondant via des informations UA pour le rendu, et la couche de rendu fournit des modèles qui s'adaptent à plusieurs bornes en fonction des pré-Conventions.
L'avantage de cette solution est qu'il maintient l'unité des données de données et de contrôle, et la logique métier ne peut être appliquée à tous les terminaux qu'une seule fois. Cependant, ce scénario ne convient qu'aux applications à faible interactive telles que les pages d'affichage. Une fois que l'entreprise est plus complexe, les contrôleurs de chaque terminal peuvent avoir leur propre logique de traitement. S'ils partagent toujours un contrôleur, cela rendra le contrôleur très gonflé et difficile à entretenir, ce qui est sans aucun doute un mauvais choix.
Adaptations construites sur le routeur
Afin de résoudre les problèmes ci-dessus, nous pouvons distinguer les appareils sur le routeur et les distribuer à différents contrôleurs pour différents terminaux:
Il s'agit également de l'une des solutions les plus courantes, principalement manifestées dans l'utilisation d'un ensemble distinct d'applications pour différentes terminaux. Par exemple, lorsque la page d'accueil PC Taobao et la version WAP de la page d'accueil de Taobao, lorsque différents appareils visitent www.taobao.com, le serveur redirigera vers la version WAP de la page d'accueil de Taobao ou la version PC de la page d'accueil Taobao via le contrôle du routeur. Ce sont deux ensembles d'applications complètement indépendants.
Cependant, cette solution entraîne sans aucun doute le problème que les données et une partie de la logique ne peuvent pas être partagées. Divers terminaux ne peuvent pas partager les mêmes données et la même logique métier, ce qui entraîne beaucoup de travail répétitif et est inefficace.
Afin de soulager ce problème, quelqu'un a proposé une solution optimisée: dans le même ensemble d'applications, chaque source de données est toujours abstraite dans chaque modèle et fournie aux contrôleurs de différents terminaux pour combinaison:
Cette solution résout le problème que les données précédentes ne peuvent pas être partagées. Sur le contrôleur, chaque terminal est toujours indépendante les uns des autres, mais peut utiliser le même lot de sources de données ensemble. Au moins, il n'est pas nécessaire de développer des interfaces indépendantes pour les types de terminaux dans les données.
Dans les deux solutions basées sur le routeur ci-dessus, en raison de l'indépendance du contrôleur, chaque terminal peut implémenter une logique interactive différente pour ses propres pages, garantissant une flexibilité suffisante pour chaque terminal lui-même, ce qui est également la principale raison pour laquelle la plupart des applications adoptent cette solution.
Adaptations construites sur la couche de vue
Il s'agit de la solution utilisée pour les pages de commande Taobao, mais la différence est que la page de commande place la couche de rendu globale du côté du navigateur, plutôt que la couche NodeJS. Cependant, qu'il s'agisse d'un navigateur ou d'un nodejs, l'idée de conception globale est toujours la même:
Dans cette solution, le routeur, le contrôleur et le modèle n'ont pas besoin de prêter attention aux informations de l'appareil, et le jugement du type de terminal est complètement laissé à la couche d'affichage pour le traitement. Le module principal de la figure est "View Factory". Une fois que le modèle et le contrôleur ont réussi les données et la logique de rendu, ils utilisent l'usine de vue pour saisir des composants spécifiques à partir d'un tas de composants prédéfinis en fonction des informations de l'appareil et d'autres états (pas seulement des informations UA, mais aussi un environnement de réseau, une zone d'utilisateurs, etc.), puis de les combiner dans la page finale.
Cette solution présente plusieurs avantages:
La couche supérieure n'a pas besoin de prêter attention aux informations sur l'appareil (UA). Les vidéos de plusieurs terminaux sont toujours gérées par la couche de vue qui montre finalement la plus grande relation. Il ne s'agit pas seulement de l'adaptation multi-terminale, mais en plus des informations UA, chaque composant de vue peut également déterminer le modèle qu'il publie en fonction de l'état de l'utilisateur, tels que la cachette d'images par défaut à faibles vitesses de réseau et la sortie des bannières d'activité dans les zones désignées. Différents modèles de chaque composant View peuvent décider d'utiliser les mêmes données et la même logique métier à votre discrétion, fournissant une méthode d'implémentation très flexible.
Mais il est évident que cette solution est également la plus complexe, en particulier lorsque l'on considère certains scénarios d'application interactifs, le routeur et le contrôleur peuvent ne pas être en mesure de rester si purs. Surtout pour certaines entreprises avec une intégrité relativement forte, qui ne peut pas être divisée en composants eux-mêmes, cette solution peut ne pas être applicable; Et pour certaines entreprises simples, l'utilisation de cette architecture n'est peut-être pas le meilleur choix.
Résumer
Les solutions ci-dessus se reflètent chacune dans une ou plusieurs parties du modèle MVC. Si une solution ne répond pas aux besoins en affaires, plusieurs solutions peuvent être adoptées en même temps. Ou on peut comprendre que la complexité et les attributs interactifs de l'entreprise déterminent quelle solution d'adaptation multicarmelle pour laquelle le produit est plus adapté.
Comparé au schéma de conception réactif basé sur le navigateur, car la plupart des logiques de détection et de rendu de terminal sont migrées vers le serveur, l'adaptation à la couche NodeJS apporte sans aucun doute de meilleures performances et une expérience utilisateur; De plus, par rapport aux problèmes de qualité de conversion causés par certains schémas dits "d'adaptation cloud", ils n'existeront pas dans le schéma "personnalisé" basé sur la séparation frontale. La solution d'adaptation pour la séparation des extrémités avant et arrière présente des avantages naturels dans ces aspects.
Enfin, afin de s'adapter à des besoins d'adaptation plus flexibles et puissants, les solutions d'adaptation basées sur la séparation frontale seront confrontées à plus de défis!