我们应该将 App Engine Context 存储在全局变量中，而不是为每个请求创建它吗？答案

【问题标题】：Should we store App Engine Context in a global var versus creating it for every request?我们应该将 App Engine Context 存储在全局变量中，而不是为每个请求创建它吗？
【发布时间】：2014-03-18 11:21:57
【问题描述】：

我们目前为每个请求生成 App Engine 上下文。我们在其他地方读到过，这无关紧要，因为 App Engine 本质上还是会缓存上下文。

func addHandler(res http.ResponseWriter, req *http.Request) {
    c := appengine.NewContext(req)

我们的问题：将 App Engine 上下文存储在全局变量中是否有意义？

【问题讨论】：

标签： google-app-engine go

【解决方案1】：

我建议不要这样做，原因如下：

保持全局状态始终是一种危险：它可能会变得陈旧、损坏，并且通常会破坏隔离和封装。
由于 AppEngine 在您向上或向外扩展时的工作方式，您不知道该全局的真正全球化程度以及其他可能读取/写入它的请求。
并发。全局变量是并发的祸根。保持理智，不要在网络应用中使用全局变量。

【讨论】：

我怎样才能保持我的功能解耦？到处都需要上下文，即使是日志记录，也要求业务逻辑功能甚至不需要知道有请求，必须传入上下文。这使得单元测试变得更加困难。
在不了解架构细节的情况下，我想说看看有一种 MVC 风格的模式。让控制器处理请求并将任何必要的数据传递给具有业务逻辑的模型，并将需要返回的任何数据返回给控制器并将其返回给视图（无论是实际视图还是 json 响应）。
当然，这就是我们正在努力实现的目标。记录到模型内部的 syslog 或让模型发出外部 http 请求（我当前的用例）或写入数据存储似乎不需要访问初始请求。让我伤心的是模型和控制器的模糊。
是的，我遇到过您肯定需要混合/模糊模型/控制器和实用程序之间的界限的用例。鉴于平台的限制，这是“要付出的代价”。