应用程序与包中的 Golang 项目结构答案

【问题标题】：Golang project structure in an application versus a package应用程序与包中的 Golang 项目结构
【发布时间】：2017-08-10 19:01:12
【问题描述】：

我的组织使用 Rails 开发其应用程序，但我正尝试用 Golang 重写我们的一个后端流程，因为它更快。

我已经与我们公司一起为我的应用程序构建了一个命名空间 (example.co)，并为我的应用程序中的每个包创建了一个子文件夹。

我包含的每个库（例如sqlx 等）也都有自己的文件夹。

src/
  github.com/
    jmoiron/
      (sqlx package files)
  example.co
    my_app/
      (my app package files)
    model/
      (model package files...)

However looking at other packages like sqlx，他们似乎完全放弃了这个目录结构，并将所有文件放在根目录中

这是因为我正在编写一个应用程序，而 sqlx 是一个旨在包含在其他应用程序中的包吗？还是只是偏好不同，因为没有真正公认的“标准”

【问题讨论】：

如果您还没有这样做，请阅读golang.org/doc/code.html。sqlx 包旨在使用“go get”进行安装。从GOPATH中的根目录到sqlx目录的目录结构是由go get创建的。我建议配置你的 Go 工作区（通过设置 GOPATH），运行 go get github.com/jmoiron/sqlx 并查看生成的目录结构。

标签： go

【解决方案1】：

我在第一个项目中也这样做了。从那以后我了解到：

$GOPATH/bin/ pkg/ src/ 布局由go get 和类似命令构建
您可以将 .go 文件组织为单个平面项目目录或子文件夹（注意：同一文件夹中的所有 .go 文件必须具有相同的包名称）
将其他人的代码放在项目根目录内的 /vendor 目录中，如果这是您的应用需要运行的代码（谷歌这个，这是 go imo 最糟糕的部分）
将您自己的项目放在您的 gopath 下，如果您希望它更易于访问，请对其进行符号链接

所以我想你的代码可能看起来像：

/Users/user2490003/MyGoPath/
▾ src/github.com/user2490003/myproject/
  ▾ model/
      user.go
  ▾ myapp/
      myapp.go
  ▾ vendor/github.com/jmoiron/sqlx/
      sqlx.go
    main.go

导入完整的包引用，如下所示：

// main.go
package main
import (
  github.com/jmoiron/sqlx
  github.com/user2490003/myproject/myapp
  github.com/user2490003/myproject/model
)

【讨论】：

感谢您的详细解释。根据您正在开发的应用程序类型，是否正在比较像我目前使用的目录结构与平面目录结构相比是否更好？
@user2490003 我个人偏爱文件夹，尽管扁平结构意味着您永远不会迷路。记住不同的包需要不同的文件夹。我不能说任何一个都“更好”

【解决方案2】：

我建议从看起来合乎逻辑且在当前可用的布局开始，然后在您的应用程序增长和发展时根据需要重构/重组。

使用你的公司命名空间是合理的——我会考虑在它下面为你的应用程序创建一个目录（例如company.co/my_app）和它内部，库包的子目录（例如company.co/my_app/db等）以及cmd 包含您要生成的实际可执行文件（package main 程序）的目录：cmd/exe1、cmd/exe2 等。这将允许您拥有多个可执行文件以及多个库“子包” my_app 的内部，可以独立包含在相应的导入路径中。

我包含的每个库（例如 sqlx 等）也都有自己的文件夹。

如果您可以使用来自 Github 的最新版本的依赖项，则不必将依赖项的代码包含到您的存储库中，而是使用 go get 将它们安装到构建区域中。如果您想从本地副本构建 - 并且对于企业用途，它可能更适合稳定性和审计跟踪 - 您应该将它们放在 vendor 子目录中，例如 company.co/my_app/vendor/github.com/jmoiron/sqlx。这样，您可以控制何时升级到较新版本的依赖项，并确保上游更改不会在您不知情的情况下破坏您的构建或以其他方式影响您的程序，直到您有机会进行彻底的测试。

【讨论】：