页面组件化的架构设计与思考

本文主要用于分享前后端组件化架构设计的实践经验与思考。

现状

职责不清：前后端没有明显的业务边界，业务逻辑耦合严重；

职责不清会让需求拆解和分析造成困扰，也会造成逻辑的前后端的高度耦合，提高后期的维护成本。

由于页面的任何改动都需要前后端的支持，整体改动的开发联调工作量以及排期冲突问题都难以接受。

页面性能：前后端交互逻辑由于年久失修，存在大量的无效请求和重复请求；

由于页面存在大量的无效业务逻辑和资源请求，导致页面渲染性能较差，影响用户体验；

后端的无效资源请求对服务器和数据库都会造成不必要的压力，属于 资源的浪费 ；

目标

O1：开发提效

从根本上解决前后端耦合的问题，前端仅关注组件化通用能力的建设，业务逻辑全部内聚在后端；

页面的动态渲染功能实现配置化、定制化，用于满足不同改动量的需求；

O2：体验优化

后端接口调用链路优化，提高资源利用率，减少无效请求和无效的处理逻辑；

页面资源依赖优化，从整体页面的视角来分析解决页面渲染性能的问题；

落地

考虑到页面逻辑比较复杂，需要人肉来分析识别有效的业务逻辑，因此拆分两个阶段来完成目标：

阶段1：梳理前端的业务逻辑，优化无效的资源请求，业务逻辑内聚在后端

阶段2：页面组件化schema设计，实现组件spi扩展、资源自动装配等能力

阶段1

阶段1主要解决了页面渲染层面业务逻辑的耦合问题，初步实现了前后端分离的目标。

• 前后端业务逻辑梳理汇总
• 页面抽象和页面组件化拆分
• 后端资源加载内聚统一

业务逻辑的梳理是关键，为了避免逻辑的遗漏，通过开发和测试的不同视角来分析和对比业务逻辑：

• 开发：从代码层面，阅读前后端的代码逻辑并梳理出一套页面业务逻辑；
• 测试：从功能层面，覆盖页面的所有case用例输出一套页面的测试case;

为了实现页面的自动降级和分段加载，需要对页面整体做一次组件化抽象，拆分思路如下：

• 按职责拆分：以功能属性来拆分组件，组件功能内聚（职责单一）；
• 按顺序加载：以功能的优先级来分组组件，分段来加载不同组件，实现页面加载的体验优化；

基于上下文的思想实现页面依赖资源的统一管理，避免资源的重复加载造成的性能问题；

public class Context {

    private AResource aResource;
    private AResource bResource;
    private AResource cResource;
    
    public Context(AResource aResource, ...) {
        ....
    }
}

阶段2

阶段2主要解决组件的扩展能力以及资源管理的进一步优化。

写时复制

组件的通用化设计不仅包含展示层面的组件设计，也包含表单、联动的设计模式。

组件的抽象定义是为了解决组件的复用性，通过定义通用的展示、表单组件，实现自定义的页面组件渲染能力。

为了提高页面的扩展能力，对于通用组建提供基于SPI的扩展点，业务上可以很快的实现组件的重载和扩展，同时对不同的业务实现业务的隔离。