nodejs 实践:express 最佳实践 (一) 项目结构

来源:互联网 发布:linux 密码修改 编辑:程序博客网 时间:2024/05/26 03:51

express 最佳实践 (一)

第二篇: express 最佳实践(二):中间件

最近,一直在使用 nodejs 做项目,对 nodejs 开发可以说深有体会。

先说说 nodejs 在业务中的脚色,, 在 web同构 方面, nodejs 的优势相对于其他语言来说,可以说非常巨大,基本上算是只有 nodejs 能做,其他语言根本不能做。在传统 web 开发方面,nodejs(必竟时间太短了)的相对于其他语言来说的劣势,已经不是太明显了。

再来说说自己,算了算差不多做了 5 个项目,都是使用 express 做为项目的基础框架,然后再上面进行业务开发工作,一个路由下来,平均 10 个左右的中间件,执行效率都是不错的,开发效率也非常好,是时候总结一下 express 实践经验,同时结合配套自己的想法,来看看理想中 express 项目应该是怎样的规划,以及我是怎么想的。

思想

做一个项目的规划,首先要为项目订一个基调,就是项目架构是应该怎样设计,怎样考虑的,对业务开发是否方便,部署是否方便等要素。

我现在认为一个项目最重要的规划是:核心+插件式开发。一个项目一定要支持这两点,如果不支持这个项目就很难做下去,为什么我这样说。因为现在的任何一个项目都不可能是一个人开发,一定是多人分工开发,如果你的项目支持核心+插件式开发,你就可以把核心的基础功能如:网络,日志,基础布局等功能,找个高级工程师来完成;业务开发,就可以分给一些初级工程师,并行完成,同时在做项目的时候对代码码进行审查,及时调整坏代码。这样项目,能保证进度,也能保证项目质量,不会大烂,同时人力也得到了充分利用。

这种思想落实到架构上,就是从项目的文件组织结构上考虑怎样达到这样的目标。

我是这样规划文件目录的:

按业务特性而不按分层进行规划

分层最典型的代表就是ruby on rails,app 目录下,就是 controllers, models等目录,当然我不是说,这种规划不好,只是到项目大到一定程度,你想找某个 controller 下的一个方法,就会很麻烦,不知道没有这种体验,在几十个文件中找某个方法是怎样的感觉,搜索也是全文搜索,不能限定到某个目录下面。因此在这个项目规划中,以业务特征为插件名,在 express 中,也就是 subExpress,如果,我有一个购物车的业务,那于购物车相关的所有的项目都规在passport 这个子应用下了,这样相关的业务在一起,方便查找,同时也方便理解和修改。当然这种规划方式也有不方便的地方,如果想跨 subApplication 调用方法,就没有那么方便。

边界显式说明

这个跟传统的 controller, service , model 没有什么区别。还是刚才的 passport 应用,按分层进行划分,包括 controllers, services, models, views, index.js, router.js。需要说明一下,在项目中我们一再强调, controllers 中负责与 http 的连接工作,只做简单参数的验证,传参和调起 services ,禁止把 rep, res 对像做为参数传递到 services 层;services 层纯业务,没有与 http 相关的任何东西,需要数据请调用 models 中的方法;models 只于数据打交到,其它都不管。这样做的好处是什么呢? 想想看,如果相把一个页面的数据拿出来做接口,只需要简单几行就搞定了,还有如果要把框架改成 koa ,你的业务都不用重写,还有你想增加 websocket 的支持,直接在 controllers 进行调整就行了。 models的作用更明显,原来的项目是一个普通是 web 项目,models 是连接数据库的,现在技术升级要前后端分离,不用数据库了,改成调用后端的接口了,你就只用把 models 用接口实现一遍,其他不用变了。 controllers 和 models 就是你业务的边界,service 则是你业务的核心,边界实现的改变不应该影响你业务。

落实

思想利用 express 的中间件思想,达到我的架构意图,如下图所示:

图中,蓝色的部分代表业务中间件,橙黄色代表 核心中间件。在一个网站项目中核心中间件,应该包括 limiter 限流操作,这个中间件主要是防止爬虫;htaccess 改写 url,这个中间件主要用,改写网站url, 为什么要改呢?因为一但网站线上运行时,路由的规则不应发生变化,但是有时候 seo 的时候,你需要兼容新老 url 的时候,这个中间件就会非常有用,网站的业务都不用变,只用在新url 到达时,变成老的再进行处理就行了;dispatch 不是一个中间件,它的思想是用来整合各个业务线的 subApplication 和主 application 的关系的;auth 鉴权,有些页面和接口需要有用户登录,如果没有用户登录,就需要跳转到登录页面,登录完成后跳回来;clientError 和 serverError 是对错误进行统一的处理,统一显示 404 , 如果是接口的话也会统一 404 的返回码。

业务端在开发时只需要在 dispatch 的地方加入自已的模块,然后就可以开始写自己的业务,不用但心自己的文件被别人改动。

下面是项目的文件夹规划:

简单说明下:

apps 目录下就写各自的业务逻辑,用 dispatch 把 主app 与 业务 连接起来,实现起来也挺简单的:

module.exports = (app) => {  app.use('/passport', require('./apps/passport'));}

还有 shared 的存在,是为了解决前后端模板公用的问题。

与业务没有关系的代码可以,移到到 modules 中使用。

如果个业务的之间需要共享部分代码,就放到 utils 中,这个文件夹就是用来干这种事的。

总结

这个项目中规划就是,怎样使用 express 最好,另外再加上自己的一些思考,现在项目的结构出来了,后面会再讨论一些有关中间件的处理方法。

该项目的 github