|
|
|
@ -9,7 +9,7 @@ |
|
|
|
|
|
|
|
|
|
# 设计目标 |
|
|
|
|
|
|
|
|
|
* 性能优异,不应该惨杂太多业务逻辑的成分 |
|
|
|
|
* 性能优异,不应该掺杂太多业务逻辑的成分 |
|
|
|
|
* 方便开发使用,开发对接的成本应该尽可能地小 |
|
|
|
|
* 后续鉴权、认证等业务逻辑的模块应该可以通过业务模块的开发接入该框架内 |
|
|
|
|
* 默认配置已经是 production ready 的配置,减少开发与线上环境的差异性 |
|
|
|
@ -30,7 +30,7 @@ |
|
|
|
|
|
|
|
|
|
`blademaster`处理请求的模式非常简单,大部分的逻辑都被封装在了各种`Handler`中。一般而言,业务逻辑作为最后一个`Handler`。 |
|
|
|
|
|
|
|
|
|
正常情况下每个`Handler`按照顺序一个一个串行地执行下去,但是`Handler`中可以也中断整个处理流程,直接输出`Response`。这种模式常被用于校验登陆的`middleware`中:一旦发现请求不合法,直接响应拒绝。 |
|
|
|
|
正常情况下每个`Handler`按照顺序一个一个串行地执行下去,但是`Handler`中也可以中断整个处理流程,直接输出`Response`。这种模式常被用于校验登陆的`middleware`中:一旦发现请求不合法,直接响应拒绝。 |
|
|
|
|
|
|
|
|
|
请求处理的流程中也可以使用`Render`来辅助渲染`Response`,比如对于不同的请求需要响应不同的数据格式`JSON`、`XML`,此时可以使用不同的`Render`来简化逻辑。 |
|
|
|
|
|
|
|
|
|