Prefacio
El uso de Node para separar el modelo de desarrollo delantero y trasero trae algunas ventajas de rendimiento y proceso de desarrollo, pero también enfrenta muchos desafíos. Bajo la compleja arquitectura comercial y técnica de Taobao, el backend debe confiar en Java para construir la infraestructura y proporcionar interfaces comerciales relevantes para que el front-end lo utilice. Una de las tareas más importantes del nodo en todo el entorno es representar estas interfaces comerciales para facilitar la integración de datos en el front-end (lado del nodo y lado del navegador) para la representación de la página. Cómo hacer un buen trabajo en el trabajo de agencia para que después del desarrollo delantero y trasero aún pueda estar conectado sin problemas en el proceso, sea un problema que debemos considerar. Este artículo discutirá este tema y propondrá soluciones.
Dado que el backend proporciona una variedad de interfaces, los desarrolladores también pueden tener una variedad de formas de escribir código del lado de nodo para acceder a estas interfaces. Si no realizamos el procesamiento de arquitectura unificada en los métodos y el uso de acceso a la interfaz, provocará los siguientes problemas:
1. Cada desarrollador usa su propio estilo de código para escribir el código de acceso de interfaz, causando confusión en el directorio del proyecto y el estilo de codificación, lo que hace que sea relativamente difícil de mantener.
2. Cada desarrollador escribe su propio método de datos simulados. Después de completar el desarrollo, necesita modificar manualmente el código para eliminar el simulacro.
3. Para realizar la conmutación de diferentes entornos de la interfaz (diariamente, pre-tema, en línea), cada desarrollador puede mantener algunos archivos de configuración.
4. El método de llamadas de interfaz de datos no puede reutilizarse fácilmente por varios modelos de negocio.
5. El acuerdo de descripción para la interfaz de datos se dispersa en cada esquina del código, que puede ser inconsistente con los documentos de interfaz acordados por el personal de backend.
6. Después de distribuir todo el proyecto, el costo de conectar interfaces o regresión de pruebas sigue siendo muy alto, y debe involucrar a cada proveedor de interfaz y usuario.
Por lo tanto, esperamos tener un marco de este tipo que utilice el mecanismo proporcionado por este marco para describir todas las interfaces externas que dependen de los proyectos de ingeniería, administrarlas de manera unificada y proporcionar métodos de modelado y llamadas de interfaz flexibles, así como convenientes métodos de entorno en línea y entorno de producción para combinar sin problemas. Modelproxy es un marco liviano que cumple con tales requisitos. Es uno de los componentes centrales del marco Midway y también se puede usar solo. El uso de ModelProxy puede traer las siguientes ventajas:
1. Diferentes desarrolladores tienen métodos de escritura de código de acceso de interfaz unificada, un significado claro y reducen la dificultad de mantenimiento.
2. El marco adopta el modo Factory + Singleton para realizar múltiples multiplexación de la configuración de la interfaz al mismo tiempo. Y los desarrolladores pueden personalizar y ensamblar sus propios modelos de negocio (inyección de dependencia).
3. Puede cambiar fácilmente entornos en línea, diarias y previos a los problemas.
4. Motores simulados incorporados como River-Mock y Mockjs, siempre que los datos simulados son muy convenientes.
5. Use archivos de configuración de interfaz para administrar las descripciones de dependencia de la interfaz de manera uniforme para evitar ser dispersos en varios códigos.
6. Admite el intercambio de modelos en el lado del navegador, que puede usarse para representar datos frontales. Todo el proceso de proxy es transparente al navegador.
7. El archivo de configuración de la interfaz en sí es un documento de descripción estructurado, y el documento se puede generar automáticamente utilizando la colección de herramientas de River. También se puede utilizar para las pruebas de interfaz de automatización relacionadas para formar un circuito cerrado en todo el proceso de desarrollo.
Diagrama de principio de trabajo de ModelProxy y diagrama de proceso de desarrollo relacionado
En la figura anterior, el desarrollador primero debe describir todas las dependencias de la interfaz de backend en el proyecto y escribirla en el archivo de configuración de interfaz.json de acuerdo con el formato JSON especificado. Si es necesario, se debe escribir un archivo de reglas para cada interfaz, es decir, la interfaz regula parte de la figura. Este archivo de regla se utiliza para burlarse de los datos durante la etapa de desarrollo o para usar el conjunto de herramientas de River para verificar la interfaz durante la etapa de depuración conjunta. El contenido del archivo de regla depende de qué motor simulado se use (como Mockjs, River-Mock, etc.). Después de completar la configuración, puede crear su propio modelo de negocio en el código de acuerdo con sus necesidades.
Aquí hay un ejemplo simple:
【Ejemplo 1】
El primer paso es crear la interfaz de archivo de configuración de la interfaz.json en el directorio del proyecto y agregar la definición JSON de la interfaz de búsqueda principal.
La copia del código es la siguiente:
{
"Título": "Definición de recopilación de interfaz de datos del proyecto Pad Taobao",
"Versión": "1.0.0",
"Motor": "Mockjs",
"RuleBase": "./interfacerules/",
"Estado": "en línea",
"Interfaces": [{
"Nombre": "Interfaz de búsqueda principal",
"ID": "Search.getItems",
"URLS": {
"en línea": "http://smtaobao.com/client/search.do"
}
}]
}
Paso 2 Crear y usar el modelo en el código
La copia del código es la siguiente:
// Introducir el módulo
var modelproxy = require ('modelproxy');
// La inicialización global introduce archivos de configuración de la interfaz (nota: la inicialización funciona solo una vez)
ModelProxy.init ('./interface.json');
// Para obtener más modo de creación, consulte el siguiente artículo
var searchModel = new ModelProxy ({
SearchItems: 'Search.getItems' // Nombre del método personalizado: la ID de interfaz definida en el archivo de configuración
});
// Usar modelo, Nota: Los parámetros requeridos para llamar al método son los parámetros requeridos para la interfaz real.
SearchModel.SearchItems ({Q: 'iPhone6'})
//! ¡Tenga en cuenta que debe llamar al método hecho para especificar la función de devolución de llamada para obtener los datos obtenidos llamando a SearchItems de manera asincrónica anterior!
.done (función (datos) {
console.log (datos);
})
.Error (function (err) {
console.log (err);
});
La riqueza de características de ModelProxy es que admite varias formas de perfiles para crear modelos de negocio que requieren negocios:
Cree un objeto usando ID de interfaz> tomará la palabra después de la última '.' número de identificación como nombre del método
La copia del código es la siguiente:
ModelProxy.Create ('Search.getItem');
Use el valor clave del objeto JSON> Nombre del método personalizado: ID de interfaz
La copia del código es la siguiente:
ModelProxy.Create ({
getName: 'session.getusername',
getMyCarts: 'Cart.getCarts'
});
Use el formulario de matriz> tomar la palabra después de la última. número como nombre del método
Los nombres de llamadas de método generados en el siguiente ejemplo son: CART_GETItem, GetItem, Sugerir, GetName
La copia del código es la siguiente:
ModelProxy.Create (['CART.GetItem', 'Search.getItem', 'Search.suggest', 'session.user.getName']);
Formulario de prefijo> Todas las ID de interfaz que satisfacen el prefijo se introducirán en el objeto y la última parte se toma como el nombre del método
La copia del código es la siguiente:
ModelProxy.Create ('Search.*');
Al mismo tiempo, utilizando estos modelos, puede implementar fácilmente solicitudes de fusión o solicitudes de dependencia y representar plantillas relacionadas
[Ejemplo 2] Solicitud de fusionar
La copia del código es la siguiente:
VAR MODELL = nuevo ModelProxy ('Search.*');
// Solicitud de fusión (el método del modelo llamado a continuación se especifica al configurar la ID de interfaz excepto para Lets)
Model.suggest ({Q: 'femenino'})
.list ({palabra clave: 'iPhone6'})
.getNav ({Key: 'Popular Clothing'})
.Done (function (data1, data2, data3) {
// El orden de los parámetros es consistente con el orden de las llamadas de método
console.log (data1, data2, data3);
});
[Ejemplo 3] Solicitud de dependencia
La copia del código es la siguiente:
VAR MODELO = NEW MODELPROXY ({
getUser: 'session.getuser',
getMyOrderList: 'Order.getOrder'
});
// Obtenga primero la ID de usuario y luego obtenga la lista de pedidos basada en el número de identificación
modelo.getuser ({sid: 'fdkaldJfgsakls0322yf8'})
.done (función (datos) {
var uid = data.uid;
// La solicitud de datos secundarios depende del primer número de identificación obtenido
this.getMyOrderList ({id: uid})
.done (función (datos) {
console.log (datos);
});
});
Además, Modelproxy se puede usar no solo en el lado del nodo, sino también en el lado del navegador. Simplemente presente el Modelproxy-Client.js proporcionado por el paquete oficial en la página.
[Ejemplo 4] Uso de ModelProxy en el lado del navegador
La copia del código es la siguiente:
<
<script src = "modelproxy-client.js"> </script>
<script type = "text/javaScript">
Kissy.use ("ModelProxy", function (S, Modelproxy) {
//! Configure la ruta básica, que es consistente con la ruta de intercepción configurada en el segundo paso!
// ¡Y hay una configuración global y solo una vez!
ModelProxy.Configbase ('/Model/');
// crear un modelo
var searchModel = ModelProxy.Create ('Search.*');
Searchmodel
.list ({Q: 'ihpone6'})
.list ({Q: 'Shangchao'})
.Suggest ({Q: 'I'})
.getNav ({Q: 'skate'})
.Done (function (data1, data2, data3, data4) {
console.log ({
"list_ihpone6": data1,
"list_shocksuit": data2,
"Sugerir_i": data3,
"getNav_SkateBoard": Data4
});
});
});
</script>
Al mismo tiempo, ModelProxy se puede usar con Midway-XTPL, otro componente central de Midway, para realizar el intercambio completo de datos, plantillas y procesos de representación relacionados en el navegador y el lado del servidor. Para obtener tutoriales detallados y documentación sobre Modelproxy, muévase a https://github.com/purejs/modelproxy
Resumir
ModelProxy existe como un marco ligero configurado, que proporciona métodos de uso y ensamblaje de modelos de interfaz amigables, y al mismo tiempo resuelve el problema de especificación de uso de la interfaz en la separación de los modos de desarrollo front-end y back-end. Durante todo el proceso de desarrollo del proyecto, la interfaz siempre debe definirse y describirse una vez, y los desarrolladores frontales pueden hacer referencia a ella. Al mismo tiempo, la herramienta River se utiliza para generar automáticamente documentos, formar un contrato con los desarrolladores de back-end y realizar pruebas automatizadas relacionadas, optimizar en gran medida todo el proceso de desarrollo de ingeniería de software.
【Nota】 El río es un término general para las especificaciones de la interfaz unificada front-end y las herramientas relacionadas desarrolladas por Alibaba Group y desarrolladas por Alibaba Group.