前端实现业务，后端处理数据。在现代框架实现前后端分离后，前后端的交互基本分为2种： 数据读取和数据写入。而前端由于业务的复杂性，也存在开发效率低，组件话实施困难的难点。本篇就是探讨我目前的解决方案。
数据读取
MVC的开发模式： 前后端商量好数据结构 -> 后端完成API开发 -> 前端根据API的参数实现业务逻辑。
这样的问题在于：
- 可能会重复开发很多类似的接口
- 由于不同人参与项目，同一个参数可能会有不同命名方式，取数方法也可能重复
- 沟通成本高
解决方式：
- 业务驱动，由更靠近业务的前端来决定需要什么数据，在mutation中就定义好需要那些字段，向后台索取
- 后台准备好所有的数据的获取方式，根据前端的需求给出
- 后台的数据尽量扁平，层级控制在2级之内
如图所示，前端展示需要Person.name等几个信息，于是发出请求向后端索取。
在后端的库里已经有一个Person相关所有参数的getter，只要根据前端需要的数据提供即可。
后端的getter中可以看到，所有参数来自与几个不同的库，有Person这个主要的库，也有PersonJob，PersonProfile等从属与Person的库。我们把多层级的库在getter层合并为同一层级，这样对于前段来说更加清晰。同时，字段名称也可适当更改，来帮助前端更利于理解。
如此一来，在开发时，新的顺序为：
- 前端通过getter选取需要的参数，如果参数不存在，让后端新增此参数
- 前端并获取所需数据，实现业务逻辑
前后端的开发就清晰了很多，代码复用率大大提高，效率明显提升
数据写入
写入的操作更为复杂，可能create，update或delete，可能是表单触发或点击按钮触发，可能是单一model修改，也可能牵连到多个model。所以，写入操作即要让代码有序，又要能够很灵活的开发，避免业务复杂后大量的if-else
解决方式
- 通过setter，定义常规的model修改逻辑，如修改personJob时一定会修改personJobStatus
- 通过插件，可在API调用前后，或某个model修改前后，或某个model参数修改前后，触发插件模块化的代码，来达到解耦的目的。如输入的是rawData，在修改Person.salary前，插入绩效规则的代码块，把rawData经过绩效规则的计算后转化为salary，在通过setter走常规的流程，计入PersonJob.salary中。由于绩效规则的多变行，通过插件配置的方式把不同的项目的绩效逻辑分离，达到解耦的效果。
前端组件化
可配置化，理想的情况是有一个后台，前端的标准组件，如form，list，card等都由configureable封装，有一个前端配置UI可以看到那个页面放置了哪些组件，有哪些配置项，然后由配置UI配置好后对改组件进行灵活的风格化。
可配置项包含组件参数，组件API调用，组件位置等
如此一来，前端开发就类似于搭积木，把几个组件一搭，一些可能会经常改动或多变的业务需求放置在后台配置，一个页面就出来了。
配置UI
最最重要的是，无论是前端配置，后端插件配置，还是后端可提供的参数，都需要一个好用方便的配置UI界面来理解和操作。这样才能化解因为框架所带来的额外的学习成本和理解成本。
