Gorilla mux 路由在子文件夹中的单独文件中？

Question

我正在尝试构建一个非常简单的 Go web 应用程序，而 golang “每个包一个文件夹” 结构让我遇到了困难。

我使用 github.com/gorilla/mux 作为路由器，使用 github.com/unrolled/render 进行模板渲染。这意味着我需要在应用启动时创建一个新的路由器和一个新的渲染器，并且我需要我的所有路由来访问渲染器。

这在单个文件中非常容易做到:

func main() {

  ...

  r := render.New(render.Options{
    // a lot of app specific setup
  })


  mux.HandleFunc("/", func(w http.ResponseWriter, req *http.Request) {
    r.HTML(w, http.StatusOK, "myTemplate", nil)
  })

  ...

然而，这是我不理解 Go 的地方。因为我希望子文件夹中单独文件中的路由(我的项目会增长)，这迫使它们位于 routes 包中。当然，这使得渲染器变量不可访问。我不能只在 routes 包中创建渲染器，因为 render.New() 调用依赖于我传递大量应用程序特定的东西，比如模板文件夹和 Assets 路径的助手。

我沿着路线让我的处理函数在一个已经初始化渲染器的结构上工作...

func (app *App) Hello2(w http.ResponseWriter, r *http.Request) {
  app.Renderer.HTML(w, http.StatusOK, "myTemplate", nil)
}

但我仍然很困惑，当它在 main routes 包中的这个 app *App。如果你有一个简单的文件列表，Go 中的一切看起来都非常容易，但是一旦你想要一些文件夹结构，包设置就会出现问题。

我可能在这里遗漏了一些东西，因此非常感谢您的帮助。

Answer 1

这是 general info on dealing with dependencies in Go .一个关键技巧是，您只需在 View 可以导入的包中声明 Render 变量。您可以创建一个包含 var Render 的 myapp/render 包，它可以在包本身中初始化(func init())或从 主要。

但是您发现的上下文听起来完全正常，尽管它可能超出了该应用程序的需要。它的巧妙之处在于，因为上下文是在每个请求代码中设置的，以后你可以扩展它来做一些偷偷摸摸的事情，比如使用 Host: header 来提供不同的 Layout 用于通过不同域加载应用程序的人。如果 Layout 被烘焙到全局中，则不能。这可能是一个真正的优势——我已经尝试将每个请求的更改改进到大型代码库中，这些代码库的配置被喷洒在各种全局变量周围，这很痛苦。