Préface
L'utilisation du nœud pour séparer le modèle de développement avant et arrière apporte des avantages de performance et de développement, mais fait également face à de nombreux défis. Dans le cadre de l'architecture commerciale et technique complexe de Taobao, le backend doit s'appuyer sur Java pour construire l'infrastructure et fournir des interfaces commerciales pertinentes à l'utilisation frontale. L'une des tâches les plus importantes de nœud dans l'ensemble de l'environnement est de procurer ces interfaces commerciales pour faciliter l'intégration des données sur le frontal (côté nœud et côté navigateur) pour le rendu des pages. Comment faire du bon travail dans le travail d'agence afin qu'après le développement avant et arrière puisse toujours être connecté de manière transparente dans le processus, est un problème que nous devons considérer. Cet article discutera de cette question et proposera des solutions.
Étant donné que le backend fournit une variété d'interfaces, les développeurs peuvent également avoir une variété de façons d'écrire du code côté nœud pour accéder à ces interfaces. Si nous n'effectuons pas de traitement d'architecture unifié dans les méthodes d'accès à l'interface et l'utilisation, cela entraînera les problèmes suivants:
1. Chaque développeur utilise son propre style de code pour écrire du code d'accès à l'interface, provoquant une confusion dans le répertoire du projet et le style de codage, ce qui le rend relativement difficile à maintenir.
2. Chaque développeur écrit sa propre méthode de données simulées. Une fois le développement terminé, il doit modifier manuellement le code pour supprimer la simulation.
3. Afin de réaliser la commutation de différents environnements de l'interface (quotidien, pré-émission, en ligne), chaque développeur peut maintenir certains fichiers de configuration.
4. La méthode d'appel d'interface de données ne peut pas être facilement réutilisée par divers modèles commerciaux.
5. L'accord de description de l'interface de données est dispersé dans tous les coins du code, qui peut être incompatible avec les documents d'interface convenus par le personnel backend.
6. Une fois l'ensemble du projet distribué, le coût de connexion des interfaces ou de la régression de test est toujours très élevé et il doit impliquer chaque fournisseur et utilisateur d'interface.
Nous espérons donc avoir un tel cadre qui utilise le mécanisme fourni par ce cadre pour décrire toutes les interfaces externes en fonction des projets d'ingénierie, les gérer de manière unifiée et fournir des méthodes de modélisation et d'appel d'interface flexibles, ainsi que des méthodes de commutation de l'environnement en ligne et de la production pratiques pour combiner de manière transparente le développement frontal et arrière. ModelProxy est un cadre léger qui répond à ces exigences. C'est l'un des composants principaux du cadre Midway et peut également être utilisé seul. L'utilisation de ModelProxy peut apporter les avantages suivants:
1. Différents développeurs ont des méthodes de rédaction de code d'accès à l'interface unifiées, des sens clairs et réduisent la difficulté de maintenance.
2. Le framework adopte le mode Factory + Singleton pour réaliser plusieurs multiplexages de la configuration d'interface en même temps. Et les développeurs peuvent personnaliser et assembler leurs propres modèles commerciaux (injection de dépendance).
3. Il peut facilement changer les environnements en ligne, quotidiens et pré-émission.
4. Moteurs simulés intégrés tels que River Mock et MockJS, fournir des données simulées est très pratique.
5. Utilisez des fichiers de configuration d'interface pour gérer uniformément les descriptions de dépendance de l'interface pour éviter d'être diffusée dans divers codes.
6. prend en charge le partage du modèle du côté du navigateur, qui peut être utilisé pour rendre les données frontales. L'ensemble du processus proxy est transparent au navigateur.
7. Le fichier de configuration de l'interface lui-même est un document de description structuré, et le document peut être généré automatiquement à l'aide de la collection d'outils River. Il peut également être utilisé pour des tests d'interface d'automatisation connexes afin de former une boucle fermée dans l'ensemble du processus de développement.
Diagramme de principe de travail ModelProxy et diagramme de processus de développement connexe
Dans la figure ci-dessus, le développeur doit d'abord décrire toutes les dépendances de l'interface backend dans le projet et l'écrire dans le fichier de configuration Interface.json en fonction du format JSON spécifié. Si nécessaire, un fichier de règles doit être écrit pour chaque interface, c'est-à-dire que l'interface règle la partie de la figure. Ce fichier de règles est utilisé pour se moquer des données pendant le stade de développement ou pour utiliser l'ensemble d'outils fluviaux pour vérifier l'interface pendant l'étape de débogage conjoint. Le contenu du fichier de règles dépend de quel mock moteur est utilisé (comme MockJS, River-Mock, etc.). Une fois la configuration terminée, vous pouvez créer votre propre modèle commercial dans le code en fonction de vos besoins.
Voici un exemple simple:
【Exemple 1】
La première étape consiste à créer le fichier de configuration d'interface Interface.json dans le répertoire du projet et à ajouter la définition JSON de l'interface de recherche principale.
La copie de code est la suivante:
{
"Title": "Pad Taobao Project Data Interface Collection Définition",
"version": "1.0.0",
"moteur": "mockjs",
"Rulebase": "./InterfacerUles/",
"statut": "en ligne",
"Interfaces": [{
"nom": "Interface de recherche principale",
"id": "search.getItems",
"URL": {
"en ligne": "http://smtaobao.com/client/search.do"
}
}]
}
Étape 2 Créez et utilisez un modèle dans le code
La copie de code est la suivante:
// Présenter le module
var modelProxy = require ('ModelProxy');
// L'initialisation globale introduit des fichiers de configuration d'interface (Remarque: le travail d'initialisation une seule fois)
ModelProxy.init ('./Interface.json');
// Pour plus de mode de création, veuillez vous référer à l'article suivant
var searchModel = new ModelProxy ({
SearchItems: 'search.getItems' // Nom de la méthode personnalisée: l'ID d'interface définie dans le fichier de configuration
});
// Utiliser le modèle, Remarque: Les paramètres requis pour appeler la méthode sont les paramètres requis pour l'interface réelle.
SearchModel.Searchitems ({Q: 'iPhone6'})
//! Notez que vous devez appeler la méthode Done pour spécifier la fonction de rappel pour obtenir les données obtenues en appelant SearchItems de manière asynchrone ci-dessus!
.Done (fonction (data) {
console.log (données);
})
.Error (fonction (err) {
console.log (err);
});
La richesse des fonctionnalités de ModelProxy est qu'elle prend en charge diverses formes de profils pour créer des modèles commerciaux qui nécessitent des affaires:
Créer un objet utilisant l'ID d'interface> prendra le mot après le dernier '.' Nombre d'ID comme nom de méthode
La copie de code est la suivante:
ModelProxy.Create ('search.getItem');
Utiliser la valeur de la clé JSON Objet> Nom de la méthode personnalisée: ID d'interface
La copie de code est la suivante:
ModelProxy.Create ({
getName: 'session.getUsername',
getMycarts: 'Cart.getcarts'
});
Utilisez le formulaire Array> Prenez le mot après le dernier. numéro comme nom de méthode
Les noms d'appels de méthode générés dans l'exemple suivant sont: cart_getItem, getItem, suggère, getName
La copie de code est la suivante:
ModelProxy.Create (['Cart.GetItem', 'search.getItem', 'search.suggest', 'session.user.getname']);
Formulaire de préfixe> Tous les ID d'interface qui satisfont le préfixe seront introduits dans l'objet et la dernière partie est prise comme le nom de la méthode
La copie de code est la suivante:
ModelProxy.Create ('Search. *');
Dans le même temps, en utilisant ces modèles, vous pouvez facilement implémenter des demandes de fusion ou des demandes de dépendance et rendre les modèles liés
[Exemple 2] Merger Demande
La copie de code est la suivante:
var modèle = new ModelProxy ('Search. *');
// Merge Demande (la méthode du modèle appelé ci-dessous est spécifiée lors de la configuration de l'ID d'interface sauf pour faire)
Model.Suggest ({Q: 'Female'})
.List ({mot-clé: 'iPhone6'})
.GetNav ({Key: 'Clothing populaire'})
.Done (fonction (data1, data2, data3) {
// L'ordre des paramètres est cohérent avec l'ordre des appels de méthode
console.log (data1, data2, data3);
});
[Exemple 3] Demande de dépendance
La copie de code est la suivante:
var modèle = new ModelProxy ({
getuser: 'session.getUser',
getMyOrderList: 'Order.getOrder'
});
// Obtenez d'abord l'ID utilisateur, puis obtenez la liste de commandes en fonction du numéro d'identification
Model.getUser ({sid: 'fdkaldjfgsakls0322yf8'})
.Done (fonction (data) {
var uid = data.uid;
// La demande de données secondaire dépend du premier numéro d'identification obtenu
this.getMyOrderList ({id: uid})
.Done (fonction (data) {
console.log (données);
});
});
De plus, ModelProxy peut être utilisé non seulement du côté du nœud, mais également du côté du navigateur. Introduisez simplement le ModelProxy-Client.js fourni par le package officiel dans la page.
[Exemple 4] Utilisation de ModelProxy du côté du navigateur
La copie de code est la suivante:
<! - a introduit le module ModelProxy, qui est lui-même un module standard encapsulé par Kissy ->
<script src = "ModelProxy-Client.js"> </ Script>
<script type = "text / javascript">
Kissy.use ("ModelProxy", Fonction (S, ModelProxy) {
//! Configurez le chemin de base, qui est cohérent avec le chemin d'interception configuré dans la deuxième étape!
// et il y a une configuration globale et une seule fois!
ModelProxy.ConfigBase ('/ Model /');
// Créer un modèle
var searchModel = ModelProxy.Create ('Search. *');
recherche
.List ({q: 'ihpone6'})
.List ({Q: 'Shangchao'})
.suggest ({q: 'i'})
.getnav ({q: 'skateboard'})
.Done (fonction (data1, data2, data3, data4) {
console.log ({
"list_ihpone6": data1,
"list_shocksuit": data2,
"suggère_i": data3,
"getnav_skateboard": data4
});
});
});
</cript>
Dans le même temps, ModelProxy peut être utilisé avec Midway-XTPL, un autre composant central de Midway, pour réaliser le partage complet des données, des modèles et des processus de rendu connexes du navigateur et du côté serveur. Pour des tutoriels détaillés et une documentation sur ModelProxy, veuillez passer à https://github.com/purejs/Modelproxy
Résumer
ModelProxy existe en tant que cadre léger configuré, fournissant des méthodes d'assemblage et d'utilisation du modèle d'interface amical, et en même temps, il résout le problème de spécification d'utilisation de l'interface dans la séparation des modes de développement frontal et back-end. Pendant l'ensemble du processus de développement du projet, l'interface doit toujours être définie et décrite une fois, et les développeurs frontaux peuvent le référencer. Dans le même temps, l'outil River est utilisé pour générer automatiquement des documents, former un contrat avec les développeurs back-end et effectuer des tests automatisés connexes, optimisant considérablement l'ensemble du processus de développement de l'ingénierie logicielle.
【Remarque】 River est un terme général pour les spécifications d'interface unifiées frontales et les outils connexes développés par Alibaba Group et développé par Alibaba Group.