关于互联网应用前端架构的一些思考

1、互联网应用的分类

讨论前端架构以前，首先要弄清楚互联网应用的类型，明确了本身的产品所属的类型才能打造属于本身的架构。对互联网产品进行分类，网上有不少不一样的观点。我以为分类是多维度的，可是按照交互以及功能的复杂程度来分类是比较客观的。所以，我比较认同淘宝玉伯在关于先后端开发模式中对应用的分类，如下引用玉伯的观点：

前端涉及的产品形态在业界可分为两大类：Web Pages 和 Web Apps 。

Web Pages 是浏览类的，用户主要是来看的：之内容展示为主，辅有少许交互。前端提供基础类库，开发工具化、外包化。典型：首页、营销活动、频道等等。

Web Apps 则以交互为主，用户主要是来用的。可分为两种：

• 体验类：包含大量交互，同时用户体验很重要。好比 GMail, 支付宝收银台、淘宝购物车等等。
• 功能类：包含大量交互，以功能为主，体验不是第一位的。好比后台系统、认证流程等。

1. Web Apps 的开发，前端投入了大量人力，但前端资源依旧存在潜在的瓶颈（好比新增长一条业务线时，极可能无前端去支持）。现有先后端配合的开发模式，沟通协做成本偏高，可维护性不够方便。在现有的研发模式下，前端自身的价值点也很难体现出来（花了大量时间在业务上，但获得的承认很少）。
2. 最核心的问题，依旧是先后端的解耦：如何让先后端的工做彼此更独立，如何让更合适的人作更合适的事，把事情作得更好。
3. 对于体验类，目前业界有不少新兴的解决方案：Backbone, Ember, Knockout 等等，包括 YUI 的 App framework 等。这些解决方案，都但愿后端专一于提供 REST 接口，其余的都交给前端来搞定。
4. 对于功能类的，目前业界解决方案依旧是比较老的一套，好比 GWT 等，包括 ExtJS 也是但愿能让后端搞定一切。

2、体验类应用在架构层面要解决的问题

咱们知道了本身的产品所属的类型，也知道了每一种类型业界已有的一些解决方案。是否是引入这些成熟的解决方案就能够了？实际的应用场景要复杂不少。要知道任何一个开源框架都有他的适用范围，不可能跟本身的应用100%匹配。举例说明，如下这些通信层的需求是比较常见的：

（1）统一拦截http请求，转换请求报文格式（json转xml等）

（2）接口超时或者异常则上报日志

（3）统一拦截http响应，非法JSON解析异常进行日志上报，转换响应报文的数据格式（xml转json等）

（4）添加统一的请求头部

（5）html5分块上传的特殊处理

若是咱们的MVC框架选型为backbone，要知足这些需求咱们不得不去修改backbone的通信层源码（你会发现backbone的通信层实际上是对jquery的ajax方法的又一次封装）。若是这种需求场景过多，咱们就得频繁的修改源码，最终代码将变得难以维护。引入框架必将失去一部分灵活性，这是代价。记得不久前，在infoq上看过一个facebook的前端工程师的视频，他对前端趋势的部分观点，我比较认同：前端将来的趋势应该是去框架化。每一个公司都应该根据本身的产品类型，打造属于本身的框架。固然在这个过程当中咱们能够吸收优秀框架的思想，甚至对开源框架进行必要的裁剪，复用核心功能。在架构层面咱们一般至少要解决如下问题：

一、模块化

二、视图与数据解耦

三、视图与视图解耦

四、健壮的通信层

五、DOM操做

六、工具库

七、业务层代码的水平拓展

八、减小重复代码

九、静态资源的版本管理

十、语法检查、自动打包

 

3、为体验类应用打造框架

（1）模块化。AMD（require.js、curl.js）、引入命名空间

（2）视图与数据解耦，可引入模板引擎好比：underscore的template、jquery Template、自定义模板引擎（139邮箱的Repeater）

（3）试图与视图解耦，可引入backbone的事件机制，使用trigger、on切断视图之间的直接调用

（4）健壮的通信层，建议本身封装通信层。通信层须要具有如下功能：

　　一、路由功能。接口可配置，业务层只需传递接口名称便可获取接口绝对路径，并发送ajax请求，是否须要跨域由通信层自行解决。

　　二、拦截请求，统一设置请求头部，将报文转换为接口须要的数据格式

　　三、容错能力。设置超时时间避免浏览器锁死。捕获error事件，并上报日志

　　四、拦截响应，校验接口返回的数据格式，报错则上报日志。

（5）DOM操做。引入开源JS库，jQuery当仁不让。

（6）工具库。underscore、自定义业务工具库（手机号码加8六、邮件地址解析手机号码等）

（7）业务层代码的水平拓展。新增需求，只需按照规范建立视图层与模型层，根据须要调用公共组件便可完成交互

（8）减小重复代码。抽象各业务模块的共性，组件化，业务层只需调用组件专一于业务，遵循职责单一的编码原则，从而提升代码的复用率。

（9）静态资源的版本管理。可为每个文件生成MD5值，页面引入静态文件时URL后加上MD5值，文件有更新只需从新生成MD5值便可。

（10）持续构建。语法检查、自动打包。可采用ant调用jar包（jslint、compiler.jar）

 

近期我会分别整理出每一环节的部分源码。

 

4、参考资料

http://www.infoq.com/cn/interviews/trend-of-without-framework

http://www.infoq.com/cn/news/2012/06/web-front-back-development/