码迷,mamicode.com
首页 > Web开发 > 详细

NodeJS服务端重构计划

时间:2015-08-13 08:53:54      阅读:274      评论:0      收藏:0      [点我收藏+]

标签:nodejs   服务器   重构   测试   

    不知不觉做node开发已经半年时间了,这期间写尝试着去解决了一些问题,实现了一下想法,也遇到过一些坑。是时候来梳理一下代码,规划一下接下来的工作。

现阶段我们的node服务器端代码结构是这样的:
技术分享

    乍一看好像没有什么问题,其实这其中充斥着一些重复代码,以及一些没有测试的模块,代码组织也不够合理。这些问题都是需要处理的。

先来说说几个常用的术语

  • router
    路由模块负责请求的分发,把请求转给具体的controller。controller是每个请求进来之后处理的逻辑,而route则定义了请求应该进入那个controller。

  • controller
    controller是一个完成某项任务的调度中心,不设计具体的数据库操作,也不做页面渲染。只负责获取现有的数据,加工处理,调用相应的接口把数据呈现给客户端。

  • middleware
    我们知道服务器响应一个客户端请求一般是串行的操作,由路由模块把请求分发到具体的controller,在分发到controller之前我们可以对这些数据做一些欲处理操作,例如判断请求头部的content-type字段提前把数据解析好,比如过滤一些包体过大的请求等。完成这些任务的模块一般称为中间件,也叫过滤器吧!

1. 利用MVC结构来重新布置代码

    在转nodejs开发之前写过一些PHP的代码,深受其代码结构的影响。传统的MVC架构清晰而且容易理解。看过了一些开源项目的代码结构,感觉服务器端代码结构还是有许多可以借鉴的地方。由于前端界面是基于canvas来绘制的,所以不存在传统意义上的渲染界面操作,服务器只完成一些基本的CURD操作即可。

1.1 引入Router模块

    根据具体的业务逻辑抽象在controller之前引入一个Router来分发请求。express4.x提供了一个Router函数,摈弃了之前把请求直接挂载到全局app对象上的做法(app.use(”api/a’, controler))。推荐的做法是把不同的业务模块挂在不同router对象上(app.use(‘/api/a’, webRouter))。再把router挂在app对象上。

  //之前的做法
  var app = express();
  app.post(‘/api1/a‘, ControllerA);

 //推荐做法
 var app = express();
 //user manager
 var router = express.Router();
 router.post(‘/api1/a‘, ControllerA);

 app.use(‘/api1‘, router);

1.2 把几个重复的校验操作抽象为filter(middleware)

    在一些需要验证用户是否登录的模块,需要判断用户的信息是否挂在session对象上。我们可以把这个操作抽象为一个过滤器。当我们发现几个模块都有类似的预处理操作时都可以抽象为过滤器的形式。

1.3 替换oauth模块

    服务器端集成了各种社交帐号的授权登录模块,经过几个月的测试以及趋于稳定了,不过在不同浏览器上居然还存在不一致的表现。考虑到代码后续的维护成本,还是放弃这个轮子了,nodejs有个passport模块可以来解决这个问题!

1.4 替换现有的Model模块

    我们的数据库采用mongodb,现有的model模块基于原生的驱动来封装,需要写一些新功能的时候体力活比较多,考虑放弃这个轮子。当时在写PHP程序的时候写了一个ORM模块把数据库的操作抽象成对语言对象的操作。nodejs有不少的ORM模块,考虑使用mongose或者sequelize来完成这个任务。

1.5 优化异步处理

    从接触Nodejs开发起,一个不得不正视的问题是怎么把异步处理写的优雅,简洁。有四个方式可以选择,

  • fibjs. 我们知道nodejs基于异步io,在调用一个异步函数等待返回的时候都需要注入一个回调函数。如果我们能够把这个等待处理结果的过程默认给实现了,这样就能解决回调的问题。fibjs正好可以解决这个问题。不过fibjs严重的模块侵入方式。也就是说原先的npm模块都得拿来修改。

  • 第三方异步处理模块. nodejs经过这些年的发展逐渐出现了一些开源模块来解决异步的问题,如async/eventproxy/step/等等。这些模块基于事件处理的方式来解决回调金字塔的问题。

  • Promise. Promise是一个非常优秀的理念,通过把一些小的功能函数封装成promise函数,一个复杂的请求其实就对应着一个promise函数链。简洁优雅的代码组织方式,良好的异常捕获机制都是Promise的优点。不过promise存在的一个问题是,如果一个模块用promise写好了,几乎其它与之相关的模块都得换成promise的形式。

  • KOA. koa积极拥抱ECMA6标准,其利用co模块实现,同步代码抒发异步情怀!

    koa 需要重写整个服务器模块,打算后面来干这个事情,故舍弃之。promise涉及的代码很多,不会比直接使用koa轻松多少所以也暂且放弃。打算选择一个折中的方式,一些轻量模块就直接用回调好了,相信良好的抽象能力也能解决一部分问题,较复杂的异步操作就通过第三方异步模块来完成,学习成本不大,拿来就用,何乐不为呢!

2.引入自动化测试模块

1.1 基本测试

     测试的重要性不言而喻,之前在开发的过程中也给一些比较重的模块写呢一些测试,但是都不成系统,不够完善。单元测试计划使用assert加shouldjs配合mocha来完成外加一个mock模块来完成,另外mocha可以方便的生成代码覆盖度测试报告。服务器端集成测试可以使用superagent来模块请求、校验请求结果。

1.2 pre-commit hook

     每次提交都触发测试,动态检测代码健壮性。这样也就能防范于未然了。

1.3 锁定版本

     Nodejs生态圈非常繁荣,我们项目使用的很多都是开源模块,为了保证项目稳定性,规避一些第三方模块的BUG。在测试稳定后把版本锁定。


时间计划
3 天

版权声明:本文为博主原创文章,未经博主允许不得转载。

NodeJS服务端重构计划

标签:nodejs   服务器   重构   测试   

原文地址:http://blog.csdn.net/gentlycare/article/details/47361753

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!