React Native: 三层架构模型

时间 2019-11-11

原文原文链接

React Native解决了H5的性能问题，Weex本质上也是React Native，发展很是迅速，目前有替代原生开发的趋势。本人本来是iOS Native开发的坚决支持者，本来打算从Objective-C过渡到Swift，就像在Windows平台跟着微软走同样省心省力。无奈形式比人强，省钱省人工对企业由足够的吸引力，养家糊口是现实需求，情怀不能当饭吃，因此做为前端，仍是要跟上时代步伐，多学一门技术。
在iOS Native开发中，View Controller不容易复用，代码又集中，因此不少聪明人想出了MVVM等架构模型来给View Controller减负。在React Native中，发现这种优点自然存在，好比有一个this.state，自然有界面观察者的做用，只要调用this.setState，就能更新界面，这个至关于View Model的做用了。在iOS Native开发中，须要自定义一个View Model结构体，并用上属性观察者这种特性，Swift才有，才能达到相似效果。
ES6以后，JavaScript引入了class关键字，面向对象的编程方法用起来就方便多了。同时，还有Promise和async/await，函数式编程的想法也很流行。因为本人iOS Native的编程时间更长，因此很天然地想把MVVM这种想法带过来，造成一个三层架构模型。前端

简介

简单讲，就是将原来React Native中一个registerComponent，至关于View Controller，能作完的事情，分为功能，逻辑，页面三层。将原来一个js文件能搞定的事情分散到3~4个不一样的js文件中。编程

三层文件夹.png

userInterface 用户界面层，这部分按照React Native来划分子模块。这里模块划分的标准是一张的的页面，复用的思路是组件。缓存
businessObject业务对象层。这是业务逻辑层，按照面向对象的方法划分子模块，是一个个具体的业务概念，好比信息采集，贷款申请，我的信息管理等。网络
functionModule函数模块层。这是基础函数功能模块，按照函数式编程的思想划分子模块，是一个个具体的功能函数，好比网络取数据，缓存操做等等。架构

用户界面层

用户对象层.png

page：这个表明一个个的页面，通常都是一个registerComponent处理过的，是最顶层的发起者。框架
component：这是可复用的组件。这是React Native的核心思想，框架自己也已经提供了足够丰富的组件供使用。固然这里主要的是对基础组件进行自定义组合，方便page：中的页面调用。异步
image：这是静态资源，好比图片等async
constant：这是常数集中定义的地方，好比界面共用的颜色，字体，尺寸，文字等等ide

这一层的主要工做就是集中精力把界面渲染出来，具体的功能和业务尽可能都分出去。好比，设置页面标题，虽然很简单，也经过调用下面的逻辑层来实现，不须要本身作。函数式编程

业务对象层

业务对象层.png

service：这是公共服务对象，通常以单例的方式提供。好比页面跳转，主要是url的定义，能够集中写在这里。好比本地缓存，最主要的是key值的定义，能够集中写在一个文件中。好比远程网络访问，主要是一些url和参数的定义，能够集中写在一块儿。
personal, enterprise：这个按照具体的业务划分。好比，这里是企业业务和我的业务来划分文件夹的。
Business：这个名字能够固定，固然也能够用其余名字。他的做用是承接页面分出来的工做。打个比方，页面page就像总裁，只要发号施令就能够了，好比响应保存按钮，处理文字录入等等；Business：就像是页面这个总裁的助理，将全部业务都接过来，找人完成。
ViewModel：这个是用来替代this.state的，主要保存页面须要展现的信息。须要更新的话，页面调用一下this.setState({});就能够了。相对于this.state，这个已经够好了，他的好处是能够把字段定义从页面中分离出来，而且能够用类的方式，将字段定义的更清晰，还能够提供处理函数，作一些页面逻辑工做。好比，把姓和名拼接成一个字段等。接上面的比方，ViewModel：就至关于Business：这个助理，根据page总裁的指令，给出的具体工做成果。
Model：这个通常对应于网络返回数据。JavaScript的网络传输返回的就是对象，字段还能够随时添加，很是灵活。不过没有名字，用起来跟dictionary也差很少，key基本靠猜。Model：能够用类来定义，让你们有一个共同的地方来看字段定义。固然，类能够有成员函数，提供必定的数据处理能力。
Business：是按照业务逻辑来分的，跟页面的划分标准都不同，因此Business和page之间并无一一对应的要求。好比，这里的Business：就为三个页面服务，搜索、信息输入、地址选择三个page共用。若是作成单例的话，还能够用成员变量保存状态，省去了页面之间传递数据的麻烦。
ViewModel：通常是跟具体的page一一对应的，由于这个自己定位就是相关page显示需求。固然，对于一些比较复杂的page，可能须要多个ViewModel：来共同服务。
Model：通常跟具体的网络请求或者缓存对象对应，由Business：来复杂持有和管理。对于page来讲是不可见的。page这个总裁只关心须要显示的ViewModel这种看得见的工做成果，至于实际上究竟是谁作的，具体怎么作的，只要助理Business清楚就能够了，他做为老总，没有必要知道。

函数模块层

函数功能层.png

这一层是按照函数式的编程思想来作的。对外提供的是一个个可以工做的函数。好比对话框，照相，网络访问，事件，路由等等。

 1 async function actionSheet(title = '标题',
 2                            buttons = ['第一个按钮', '第二个按钮', '第三个按钮'],
 3                            cancelButtonText = '取消',
 4                            destructiveBtnIndex = -1) {
 5     return new Promise((resolve, reject) => {
 6         AlipayJSBridge.call('actionSheet',{
 7             'title': title,
 8             'btns': buttons,
 9             'cancelBtn': cancelButtonText,
10             'destructiveBtnIndex': destructiveBtnIndex,    // 变红按钮的index
11         }, data => {
12             const index = data.index;
13             const cancelIndex = buttons.length;
14             if (index < cancelIndex) {
15                 return resolve(index);
16             } else {
17                 return reject('选择了取消按钮');
18             }
19         });
20     });
21 }
22 
23 export {
24     actionSheet,
25 };

好比这个是iOS开发中常见的action sheet，通常是Native实现，而后提供调用接口。这个是等待用户选择，而后根据选择结果进行相应处理。Native是以回调函数callback来实现异步过程的，在这里用了JavaScript的Promise包装，就能够在后续调用中使用async/await这种最新科技了。

为了方便使用，将输出接口在一个汇总文件中集中一下是个值得推荐的作法。好比:

 1 export {
 2     showLoading,
 3     hideLoading,
 4 } from './Loading';
 5 
 6 export {
 7     toast,
 8 } from './Toast';
 9 
10 export {
11     alertNative,
12     confirm,
13 } from './Modal';
14 
15 export {
16     actionSheet,
17 } from './Select';
18

不足之处

这套架构模型的优势是分工明确，将界面、业务、功能分开来，对于比较成熟的产品是比较好的。而且把如今流行的面向对象编程和面向函数编程都包括进去了。

不过对于初创产品，或者比较简单的产品来讲，体现不出优点，反而带来负担。最直白的来讲，就是太烦了。
原本要改一点东西，只要找一个js文件，就是那个page总裁页面，就能够了。如今弄得又要找business助理，还要修改function具体干活的，作完了还要转成View Model这种指定的格式... .... 链路这么长，想一想都头大，可能我只是修改一个后台返回字段而已啊，要改这么多地方... ...