隐式服务：数据查询、访问控制与模式迁移的综合解决方案

### 隐式服务：数据查询、访问控制与模式迁移的综合解决方案 #### 1. 网络调用与响应时间优化 在实际应用中，需限制单个用户操作引发的网络调用次数。按项目类型检索数据尚可接受，但为每个项目实例调用服务会使响应时间处于危险区域，这就是 ORM 工具的懒加载问题。并行提交查询并异步处理结果可减少系统总响应时间，但仅适用于查询相互独立的情况。若需检索相关数据，会出现同步行为，导致多次往返增加不必要甚至不可接受的响应时间。 解决方案是采用一种协议，允许在单次往返中处理任意组合的查询。这要求我们不再局限于检索记录或文档，而是支持任何所需结果类型。 #### 2. 服务请求与查询语言 假设要检索 ID 为 123 的客户的所有发票，服务请求的基础查询如下： ```plaintext customer [ id = 123 ] invoices ``` 但服务器应返回什么呢？可以指定要返回的具体属性，例如： ```plaintext customer [ id = 123 ] invoices: :: number :: date ``` 这意味着： - 在数据库中查找 ID 为 123 的客户。 - 查找该客户的发票。 - 为每张发票返回编号和日期字段。 还可以包含表达式，如： ```plaintext customer [ id = 123 ] invoices: :: number :: date :: lines amounts sum ``` 该服务除了返回发票编号和日期，还返回发票的总金额。 为实现完美粒度，可接受嵌套查询，例如： ```plaintext customer [ id = 123 ] invoices: :: number :: date lines: :: product name :: amount ``` 查询结果是一个层次结构，包含每张发票的编号、日期以及每行的产品名称和金额。 查询表达式还可在同一级别指定多个子查询，例如： ```plaintext customer [ id = 123 ]: :: name invoices [ not payed and due-date < today ]: :: date :: amount contact-persons: :: name ``` 也可在服务请求的根级别进行，如： ```plaintext customers [ region = 4 ]: :: name products: :: id :: name ``` 相关元素并非全新概念，类似 GraphQL，但 IR 模型不限于查询特定类型的数据，且与编程语言集成，可受益于属性链、用户定义函数等。 #### 3. 访问控制 传统基于 SOA 的应用通过服务设计、URL 授权和程序逻辑实现访问控制。但隐式服务没有特定服务实现来放置逻辑，因此需要在数据模型上直接设置访问控制。 在 VIA 架构中，借助集成的用户管理系统，服务器可知道每个服务请求的准确来源，甚至到最终用户级别。可建立细粒度的授权模型，根据用户组授予或拒绝访问每个项目、关系和属性，还可根据用户特定数据授予数据。 授权感知的编程环境可改善授权异常处理，返回无访问指示值，而不是使整个服务执行崩溃。添加通用客户端运行时处理这些异常，可减少错误。 #### 4. 更新与读取服务 在 VIA 中，可明确分离查询和更新服务，有单一通用读取服务用于所有数据检索请求，单一通用写入服务用于所有更新请求。 读取服务请求是对要检索数据的规范，可将其视为纯函数，无副作用，允许进行全面查询优化，且请求始终是幂等的。写入服务请求更像更新脚本，会使数据库从一个状态转变到另一个状态，客户端应被告知操作是否成功，通常将单个写入服务调用视为一个工作单元和单个事务。 #### 5. 模式演变与服务版本控制 数据模型是软件系统的基础，添加新功能时可能发生变化。每次数据模