Hoy, se llevaron a cabo pruebas multidimensionales del equipo de solicitud de datos de la base de datos, cuyo proceso de desarrollo se describió en detalle y muy detallado aquí y aquí .
¿Qué mostraron las pruebas? El equipo funciona, pero ... en el caso de uso en el que tiene que usarlo, es inconveniente configurarlo.
Como mencioné en la primera publicación, para cada intercambio de datos con el proveedor de servicios KYC, se deben seleccionar tantos registros de la base de datos como sea posible. Más de una docena El comportamiento del algoritmo para extraer registros de la base de datos dentro del marco de cada solicitud es idéntico, solo se cambian las configuraciones. Si escribiera por primera vez una prueba de integración que demuestra un caso de uso de combate, entendería qué detalles clave no deben pasarse por alto. Una prueba de integración podría verse así:
describe('configure and run database requests', () => { const context = require('../src/storage/requestContext'); const requestHandler = require('../src/storage/requestHandler'); it('should get full recordset from db', (done) => { for(let key of context.rules.keys()) { let handle = requestHandler.bind(context, [key]); context.store.subscribe(handle); } const assert = checkDataIsReady.bind(context, [done]); context.store.subscribe(assert); const note = { Id: 1, UserId: 38 }; const start = { type: 'NOTE', note }; context.store.dispatch(start); }); function checkDataIsReady(args) { if(notAllDataIsHereYet()) return; checkUserRecord();
La cardinalidad de la diferencia es que preparamos las reglas para la configuración de consultas por adelantado y las almacenamos en el diccionario context.rules . Y este diccionario y otros objetos necesarios para ejecutar consultas y guardar los resultados están contenidos en el contexto que recopilamos del almacenamiento de base de datos preconfigurado context.db , el almacenamiento de contenedor de estado preconfigurado context.store y el diccionario mencionado anteriormente.
Al mismo tiempo, las reglas de configuración de la consulta pueden contener datos de cadena ordinarios, por ejemplo, el nombre de la tabla desde la que se deben solicitar los datos, así como métodos de fábrica que generan consultas a la base de datos y métodos de envío que envían acciones al contenedor de estado. En esta situación, la configuración de los comandos necesarios se ve completamente diferente de lo que sugiere el código existente.
Dicha solución arquitectónica nos permite, entre otras cosas, definir varios niveles de comprobaciones KYC, simplemente en forma de conjuntos de cadenas ( Set ), que se utilizan como claves al almacenar reglas de configuración de consultas. Por ejemplo, si queremos enviar solo datos personales y una dirección para verificación, simplemente colocamos las claves correspondientes en un conjunto de líneas: user , person y address .
La prueba anterior muestra la opción de configuración máxima, omitiendo todo el diccionario de reglas y configurando un código de consulta generalizado, en tablas específicas. Bueno, como puede ver en el código a continuación, el lanzamiento real de las solicitudes se producirá como reacción a los eventos del cambio de contenedor de estado:
let handle = requestHandler.bind(context, [key]); context.store.subscribe(handle);
Hoy no se describirá el proceso de implementación en todos los detalles escalofriantes, porque aún no se ha llevado a cabo ...