Aujourd'hui, des tests multidimensionnels de l'équipe de demande de données de la base de données ont eu lieu, dont le processus de développement a été décrit en détail et très détaillé ici et ici .
Qu'est-ce que les tests ont montré? L'équipe fonctionne, mais ... dans le cas d'utilisation dans lequel vous devez l'utiliser, il n'est pas pratique de le configurer.
Comme je l'ai mentionné dans la première publication, pour chaque échange de données avec le fournisseur de services KYC, autant que possible, un nombre relativement élevé d'enregistrements doivent être sélectionnés dans la base de données. Plus d'une douzaine. Le comportement de l'algorithme d'extraction des enregistrements de la base de données dans le cadre de chaque requête est identique, seuls les paramètres sont modifiés. Si j'avais d'abord écrit un test d'intégration qui démontre un cas d'utilisation au combat, je comprendrais quels détails clés ne devraient pas être négligés. Un test d'intégration pourrait ressembler à ceci:
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 cardinalité de la différence est que nous préparons à l'avance les règles de configuration des requêtes et les stockons dans le dictionnaire context.rules . Et ce dictionnaire et les autres objets nécessaires à l'exécution des requêtes et au stockage des résultats sont contenus dans le contexte que nous collectons à partir du context.db stockage de base de données préconfiguré.db, du context.store stockage du conteneur d'état préconfiguré.store et du dictionnaire susmentionné.
Dans le même temps, les règles de configuration des requêtes peuvent contenir à la fois des données de chaîne ordinaires, par exemple, le nom de la table à partir de laquelle les données doivent être demandées, ainsi que des méthodes d'usine qui génèrent des requêtes vers la base de données et des méthodes de répartition qui envoient des actions au conteneur d'état. Dans cette situation, la configuration des commandes nécessaires est complètement différente de celle suggérée par le code existant.
Une telle solution architecturale nous permet, entre autres, de définir différents niveaux de contrôles KYC, simplement sous la forme d'ensembles de chaînes ( Set ), qui sont utilisées comme clés lors du stockage des règles de configuration des requêtes. Par exemple, si nous voulons envoyer uniquement des données personnelles et une adresse pour vérification, nous mettons simplement les clés correspondantes dans un ensemble de lignes: user , person et address .
Le test ci-dessus montre l'option de configuration maximale, en contournant l'intégralité du dictionnaire de règles et en configurant un code de requête généralisé, sur des tables spécifiques. Eh bien, comme vous pouvez le voir dans le code ci-dessous, le lancement réel des demandes se produira en réaction aux événements du changement de conteneur d'état:
let handle = requestHandler.bind(context, [key]); context.store.subscribe(handle);
Il n'y aura pas de description du processus de mise en œuvre dans tous les détails effrayants aujourd'hui, car il n'a pas encore eu lieu ...