大家好，我是编程小6，很高兴遇见你，有问题可以及时留言哦。

这里所谓的前端架构模式，是指基于VUE的技术，如何组织和编排这些前端编程能力以形成一个有体系的架构，从而指导前端编程设计的一种思路。

目标

1 以相对合理的双L结构：横向Layer和纵向Lane形成的矩阵，约束和管理数据传递方式和组件管理模式

2 通过数据视图（Data View）建立增强的数据驱动的设计理念，并建立本地缓存机制，适当减少API交互频率

3 为微服务模式下的业务装配场景提供技术便利，从不同的技术层面划分业务颗粒度，从而快速实现前端到后端的业务切割和按需组合

构建的架构设计图如下，横向一共分为5个层（Layer），每个业务通道（Lane）从前端组件开始，通过数据代理去访问数据视图，数据视图则统一通过引入API服务簇去访问特定的API。

以数据视图为核心的数据驱动机制

VUE因为是MVVM模型，因此，数据映射的这个模型的核心，那么回归业务角度再看，利用这种机制的核心是构建统一的业务视图，在业务视图中达成应该实现的所有业务变化，并通过合适的渠道进行数据分发。在该层面，我们通过Vuex的状态管理实现，且状态管理可以方便的实现数据缓冲机制，减少CRUDA等资源维护页面切换时对API资源的消耗。

因此，基于上述我们构建了两段数据链路，一是从API端到数据视图，该链路由数据视图的容器管理，从而规避数据视图上方前端组件和数据代理对API层面的穿透；二是数据视图到前端组件，我们通过数据代理负责单一职责的业务处理，从而使数据代理单元横向可以继承和叠加，纵向上可以组合。

单一职责的数据代理机制

单一职责在业务上我们锚定的是一个业务维度的处理，在技术上则锚定的是单一职责模式，它实际上是把组件的数据的要求和常见的操作和事件进行了剥离和组装，从而使数据的处理和前端的交互构建在更加稳定的机制之上。在该层面，我们通过Mixins机制实现。

最典型的是我们对资源CRUDA的封装处置，即可以设计 resource-agent 代理对象，为创建、浏览、更新、删除、审批构建可复用的单一代理，原则上，它具备以下职责：

1 从数据视图映射ActiveRecord，这是一个活动记录的概念，即由resource-agent维护一个数据视图中正在活动的数据快照，并供给前端组件进行交互，典型的，我们会构建v-model结构，用以完成前端组件和数据视图间的数据传导

2 将前端的交互需求在进行自身的解析处置后交由数据视图进行后续处置，如C、U、D、A等操作

另外，常见的数据代理有POOL，FILTER、CATEGORY、ACCOUNT等，在业务上我们不难发现，这分别代表的都是特定的业务维度。

API簇

API簇完成对微服务架构的前端对应机制，推荐的做法是把一个微服务的api独立封装成独立handler，并暴露给数据视图层面，由其按需调度。

在基于上述结构设计后，前端的编程框架实现成本上有明显的降低，相对依赖关系也较之前合理有效，感兴趣的朋友可以做一下尝试，其中若有任何问题，也欢迎一起讨论交流。