5.04 Context-Echo和Iris的Context设计分析

PART1. Echo Context设计分析

1.1 Echo Context的设计

Echo的Context被设计为接口,这一点和Beego、Gin都不太一样,但实际上,它只有1个实现context.

这意味着其他人也可以提供Context接口的不同实现,但实际上也并没有什么人去实现它.

从方法定义上来看,Echo的context和Beego、Gin的都差不多,也是维护来自各部分的输入和输出.

context struct {
	request  *http.Request
	response *Response
	path     string
	pnames   []string
	pvalues  []string
	query    url.Values
	handler  HandlerFunc
	store    Map
	echo     *Echo
	logger   Logger
	lock     sync.RWMutex
}

可以看到,和Gin的Context设计一样,Echo的Context也是自行封装了一个Response,但是使用了原生的http.Request.

context.logger:这意味着Echo把日志输出定义在了context级别上.有一种观点认为日志输出应该定义在Server上,而非Context上
context.lock:有一种观点认为Context没有必要实现线程安全.因为正常情况下1个请求打到Server端,就应该只有1个Context去处理这个请求(因为Server端的基本模型是每收到1个请求,就有1个goroutine去处理这个请求,因此应该只有1个Context).如果在中间件使用者定义的HandleFunc内部,中间件使用者自己又启动了一些goroutine,那么应该让中间件使用者自己去在他创建的这些goroutine之间确保这个Context的线程安全,而非由中间件研发者替他对Context的线程安全做出保证