Vue：可以快速移植的工程结构

概述

因为近期在做web的时候，用了很多的vue相关技术，在最早期是weex，使用中所有的web访问都乱作一团，完全没有任何结构可言，ajax始终是混合在界面文件中，导致代码就像一个被猫玩坏的毛线球一样。

这就导致了一个很严重的问题：一旦出现了bug，就很难理清楚他发生的位置，其实这也不完全是我的问题，毕竟整个开发组都这样写，晕死，不过万幸的是，毛线球还是最终进入了稳定期。

不过面对那些代码，我完全没有在过一遍的兴趣，除非是重写。

所以如果js代码能够有一个良好的结构，无论是对于后期的维护还是多端的移植，都是极好的。

参照Spring工程的结构，我后来将这些代码中所有AJAX的地址单独抽取为一个js，并且按照访问controller的不同，分别编写Service，所有的Ajax均在Service中执行，然后返回的数据到Vue的界面中，在界面里面进一步处理，让他变成展示需要的数据。

Ajax需要Http模块的支持，但是不同平台的Http方式是不一样的，微信的wx.request，浏览器的fetch或者axios，JQuery甚至是XMLHTTPRequest，还有一些奇奇怪怪的访问方式，因此Http模块应该得到抽象，各平台的js需要重写http并把这些请求包装为Promise，并导出提供给那些Service使用。

因此整理下，就是这样的：

Http模块

export为一个class，提供静态的get、post、put、delete方法，如果使用TypeScript，http应该保留为接口，在各平台上面提供此接口的不同实现，四个方法分别可以输入URL或者URL和数据，并且输出一个从服务端返回的Promise对象。

ServiceAPI模块

export为一个class的同时，也要Export一个Const的API字段，按照不同的API地址所属的controller进行分组，例如：UserController的Login：

export const API = {
	USER: {
		LOGIN: 'API地址'
	}
}

API的地址有很多地方需要拼接，这些地方，在使用的时候最好通过正则进行匹配和替换，避免直接使用加号，因为这样看起来会比较乱，虽然正则会慢一些，但是速度并不是不可接受。

仿照spring的el表达式，我制作了一个类似的东西，可以把字符串和json对象直接进行拼接：

export class ElExpr {
  static regex = /\$\{[^\^$}]+\}/g
  constructor (str) {
    this.el = str
    this.vars = str.match(ElExpr.regex)
    if (this.vars !== null) {
      this.vars = this.vars.map(elem => elem.substring(2, elem.length - 1))
    } else {
      this.vars = []
    }
  }

  spread (data) {
    let result = '' + this.el
    for (let name in data) {
      if (this.vars.indexOf(name) !== -1) {
        result = result.replace('\$\{' + name + '\}', data[name])
      }
    }
    return result
  }

  prepar (data) {
    this.preparData = data
  }

  toString () {
    if (this.preparData) {
      let result = this.spread(this.preparData)
      return result
    }
    return this.el
  }
}

那么，API常量就是包含${变量名}这样东西的El表达式，需要的时候通过ServiceAPI类提供的静态方法进行地址获取，只需要给出需要的表达式字符串以及参数，就马上可以得到一个拼接好的字符串作为URL。

我们还可以在这个方法里面提供一些默认的变量值，通过ES6的展开运算符填充到用户提供的参数中，从而在使用的时候省掉一部分默认的参数。

Service模块

直接与后端服务器交互，获取数据并封装为容易使用的js对象，不涉及具体界面，和后端功能模块一一对应，需要依赖于Http模块和ServiceAPI。

Service模块不只有一个，导出为class，提供静态方法进行数据访问。

Util模块

提供null，undefined，空字符串等空判断方法，Object的深拷贝，Object和array的相互比较等通用工具方法。

小结

这样只后，一旦需要多平台移植，我需要做的是什么呢？仅仅只剩下简单的界面编写了吧？除了Http需要根据平台进行重写，以上Service，Util、API等均可以一动不动直接移走——当然，这是最理想的情况。

其实我一直很在意一个新的特性，叫做装饰器，这个和Java的注解太像了，如果可以的话，使用装饰器和El直接代替API常量，通过AOP代理这些Service，就可以直接实现数据访问，加以封装后必然可以更加简单，不过嘛，似乎不是那么容易的。