如今，已经对数据库中的数据请求团队进行了多维测试，其开发过程已在此处和此处 详细描述，并且非常冗长 。
测试显示了什么？ 该团队可以工作，但是...在您必须使用它的用例中，配置它很不方便。
正如我在第一本出版物中提到的，对于与KYC服务提供商的每次数据交换，应从数据库中选择尽可能多的记录。 十几个。 在每个请求的框架内从数据库中提取记录的算法的行为是相同的，只是更改了设置。 如果我首先编写了一个演示战斗用例的集成测试，那么我将理解哪些关键细节不容忽视。 集成测试可能如下所示：
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();
区别的根本在于，我们预先准备了查询配置规则，并将其存储在字典context.rules 。 而且，该字典和执行查询并保存结果所需的其他对象包含在我们从预配置的数据库存储context.db ，预配置的状态容器存储context.store和上述字典收集的上下文中。
同时，查询配置规则可以包含普通字符串数据（例如，应从中请求数据的表的名称）以及生成对数据库的查询的工厂方法和将动作发送至状态容器的调度方法。 在这种情况下，必要命令的配置看起来与现有代码建议的完全不同。
这种体系结构的解决方案使我们能够除其他外，简单地以字符串集（ Set ）的形式定义各种级别的KYC检查，这些字符串在存储查询配置规则时用作键。 例如，如果我们只想发送个人数据和用于验证的地址，则只需将相应的密钥放在以下几行中： user ， person和address 。
上面的测试显示了最大的配置选项，绕过整个规则字典并在特定表上设置通用查询代码。 好的，正如您在下面的代码中看到的那样，请求的实际启动将作为对状态容器更改事件的反应而发生：
let handle = requestHandler.bind(context, [key]); context.store.subscribe(handle);
由于尚未进行实施，因此今天的所有冷却细节都不会描述实施过程。