-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
框架实现原理 #3
Comments
前言本文主要讲解如何使用TypeScript装饰器定义Express路由。文中出现的代码经过简化不能直接运行。需要完整代码的童鞋,请到github获取:https://github.com/WinfredWang/express-decorator 1 为什么使用装饰器当我们在使用Express时,经常要暴露RESTful服务,代码如下:
熟悉Java WEB童鞋知道
使用这种方式声明的服务非常简洁方便,免去了写一坨重复代码之苦。而且看起来更加清晰。那我们看看在Node.js中如何做。 2 需求参照
3 实现思路在ES6和TypeScript中有新特性: 上图中左边是Java中定义RESTful代码,右边是Express代码,其实他们本质上是一一对应的。我们只要在装饰器的定义中实现Express 路由即可。 继续思考,我们Express 路由到底是放到那个注解中实现呢?
根据这个特性我们应该将核心实现放到类装饰器 其实不是,我们看如下代码,我们在
我们定义好了服务,然后想让Node.js模块加载,我们必须在工程入口模块(main.ts)中导入上述文件
上述服务代码会执行吗?也就是说 上有政策,下有对策。我们就在模块引用一下。
这样好吗,当然不好。谁知道这是干嘛的。 所以我们应该换了思路,将Express 注册路由代码拿到装饰器外部,额外提供注册服务的入口,通过该注册服务入口,用户可以显式看到有哪些服务。
4 装饰器核心代码基于上面的思考,我们在装饰器的实现中只是单纯地存储RESTful url以及参数即可,剩下服务注册工作交给 Path装饰器实现
这里我们将RESTful路由存储到类的原型中,以便服务实例化时能获取到。 GET/POST/DELETE/PUT
QueryParam/PathParam等实现
上述就装饰自身代码,本质上就是讲路由、http请求方法和参数存储到类的原型对象中,以便后续可以去到。 4 注册服务核心代码路由实现经过上面的分析,我们可知注册服务主要将Express中注册路由交由我们框架处理,核心代码如下:
http请求参数处理
用户编码时我们期望回调函数中的参数框架自动注入,而不是让用户自己从
response处理
一个服务处理完成后,总是要向浏览器返回值的,在回调函数中直接使用
5 总结以上就是我们框架处理核心代码,核心实现主要有两步:
|
No description provided.
The text was updated successfully, but these errors were encountered: