前段时间的项目使用了Nodejs，中间经过过一次重构，基于Express框架，分享一下经验：
流程Promise化
基于Nodejs的回调语法，你会写出大量下面这种代码：
doAsync1(function () {
doAsync2(function () {
doAsync3(function () {
doAsync4(function () {})
})
})
})
这就是所谓的 “回调黑洞” 了，采用回调写法最大的问题有两个：
一是异常问题的处理，假设你的doAsync4依赖doAsync3的返回值，而doAsync3函数又依赖于doAsync2的返回值，如果doAsync2函数没有返回预想的结果，那么回调仍会继续执行，而如果你的代码里没有做良好的错误处理，可能代码会一直执行到doAsync4，debug的痛苦可想而知。
二是业务流程的变更，现在我们假设要更改业务流程，doAsync2发生在doAsync1之前，你的重构工作量有多少？
这时我们就要考虑使用Promise了，我并不打算在这里详细的介绍Promise，有趣的是SF就有对于Promise分析良好的系列文章：深入理解Promise五部曲
以及目前常见的回调写法替代方案Node.js回调黑洞全解：Async、Promise 和 Generator
上述代码如果用Promise来重构结果会是这样的：
doAsync1
.then(function (data1) {
return data1
})
.then(function (data2) {
return doAsync2(data2)
})
.then(function (data3) {
return doAsync3(data3)
})
.then(function () {
res.send('数据处理成功')
})
.error(function (error) {
res.send('Error: ' + error)
})
应用分层
在应用中分出Controller层和Model层，不要把页面渲染和逻辑都塞到Router层。理想的结果是：Controller + Model + Router + Filter，Filter层即是过滤，也可以理解为中间件，可以写一些过滤规则，比如最常见的要求用户登录：
module.exports = {
'/homepage': {
get: ['auth.requireLogin', 'auth.requireAdmin']
}
}
在项目的上一次重构中，我砍掉了Router层，增加了一层API，将页面渲染和流程都放在Controller，而数据处理都在API，这样方便未来做数据验证和单元测验：
Controller层
module.exports = {
'/customer': {
get: function (req, res) {
var userInfo = req.body.data
User
.create(userInfo)
.success(function () {})
},
post: function () {}
}
}
API层
module.exports = {
'/customer': {
get: function () {
User
.info()
.success(function (requiredData) {
res.send(requiredData)
})
}
}
}
Model层取决于你用的数据库，流程的Promise化客观上要求了你的Model也要Promise化，Node上常见数据库的ORM都提供了Promise的写法，对应去看就好了。Express并不提供这种Restful路径的写法，我参考Rabbit框架（感谢芋头）基于这个插件改了改：rainbow
最后来看看成果，重构前的代码如下：
重构之后（数据都放在API层了）：
一般来说，一个管理后台的构建的基本流程是：(1)选择一个开发语言->(2)选择一种数据库->(3)选择一个开发轮子(framework)->(4)在轮子上搭建前端框架->(5)实现业务逻辑。时下Web前端技术的发展风生水起，我们可以尝试用WebAPP的思想去构架后台，将后台的前后端分离，前端交给AngularJS，后端交给任何一种语言框架，前后端通过标准协议接口通讯，这样后台构架的流程将是这样：(1)业务流程的数据库建模->(2)业务流程的协议文档制定->(3)前后端工程师协作开发完成后台。
