我们的新前端_路由器设置网

我们的新前端

公司历史悠久的B/S办公系（称为E系统）统需要添加移动支持。

根据前期决策，公司范围将以hybrid形式作为现有系统“移动化”的标准模式。公司将有专门团队开发外层壳体，作为一个具体应用，我们提供自己的页面，只要这些网页适合手机显示。

所以我们准备新开一个项目，开发本系统适于手机的页面。

初步架构已经完成：

整体结构

SinglePageApplication

采用趋向于SinglePageApplication风格是一项比较早确定的决策。即将大部分的展示逻辑都部署到浏览器端。这和公司里面现在大量存在的类似于Spring MVC的结构非常不同。但我们认为这个风格意义很明显：

用户体验提升
移动互联网环境下性能要求
展示逻辑集中控制

虽然在现今互联网很常见，但在公司的环境中，这种风格还比较新。开发设计人员对这个风格并不熟悉，我们需要特别注意由此带来的风险，在后面“前端结构和技术”一节，将提到的一些决策，都能帮助减轻这个风险。

REST

理解REST的含义特别是必要性并不容易。

最近有一个项目，同样是OnePageApplication风格，前期准备实践REST风格，但由于大家并没有理解REST含义，架构执行过程中也没有进行修正，最终成为了JSON-RCP风格接口。

在本公司架构师之间，对REST的理解也不尽相同。很多架构师更多的思考如何使用，对于“为何要使用”这个关键问题反而思考得比较少。

在新的项目中，我们在尽量使用REST风格接口的同时，并不强求其纯粹的风格，相反，我们将通过这次实践着重思考REST的意义，特别是对我们这个企业，在这个既有环境中的意义。

业务逻辑

E系统的既有结构是Web和App各部署到一组节点，相互分离的结构，理论上讲，业务逻辑全部部署于App层，我们只要重新开发我们的Web层，即可完全利用既有的业务逻辑。但实际情况是，很多业务逻辑被放到了web层。这不是既有架构的初衷。出现这种情况的原因应该是：

开发（包括设计人员）人员知道有这个架构决策，不知道为何有这个决策。当架构执行力度降低的时候，开发人员按照自己的想法和当时环境的短期要求来组织逻辑。
系统采用Transaction script风格架构，以功能为主线条组织业务逻辑，同时又以功能为单位管理需求、开发过程，这进一步加剧了开发人员在当前功能的自由随意。

我们对E系统的层次规划类似于DDD常用的四层¹，我们希望系统的业务逻辑能全部封装在业务层（应用层或者领域层），通过REST或者其他形式的接口暴露给展示层。在项目范围内，我们将在业务层中重写一些以前在展示层的业务逻辑。同时，另一个项目正在致力于重新布置整个E系统的代码结构，两个项目如何配合，将是我们需要小心处理的问题。

前端结构与技术

模式和框架

展示逻辑将全部部署于浏览器端，我们需要考虑如何组织这些逻辑。

MVC（或者其变体，我们不做区分）简单有效，开发人员比较熟悉，没有不使用的理由。我们考察了一些相关框架，最后落脚于下面两个：

Backbone - 简单直白，社区活跃。虽然核心框架中不包含composite view、data binding等功能，但相关插件都有，可以方便的自由组合。
Ember - 功能丰富，特别是如果配合ember data，基本可以一站式解决所有问题。缺点是比较新，特别是ember data还不是“Production Ready”，遇到问题不一定能快速解决。

我们倾向于Backbone，核心框架再按需配备一些周边挂件。对于不熟悉相关领域的开发人员，这种风格相对容易学习。

语言基础

以Js作为语言开发大规模复杂逻辑，开发人员并不熟悉，需要一些支持：

模块化：模块化对于大规模的开发来说是必不可少的，但以前的开发人员却并不熟悉。这次我们选择Requirejs或者Seajs，将强制执行它们带来的模块机制。两者区别不大，就支持一下国货吧。
OO：Mootools带来类似extends、implement等OO特征，让习惯Java的开发人员非常顺手。但Backbone有自己的一点诸如继承的机制，如何协调两者关系，相关细节需要和开发人员一起研究讨论，建立示例代码。
单元测试：此类工具种类繁多，没有一一研究比较，只要有一个可用的就可以了。Qunit，必要的时候配合JSTestDriver。
遗留代码：遗留代码如何融入到上述的模块化机制，是一个还没有解决的问题。可能直接shim，也可能手工对每个文件逐个重新包装。两者优劣，需要继续研究。