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

Question

我的组织使用 Rails 开发其应用程序，但我正尝试用 Golang 重写我们的一个后端流程，因为它更快。我已经与我们公司一起构建了我的应用程序，为我的应用程序 ( example.co) 构建了一个命名空间，并为我的应用程序中的每个包创建了一个子文件夹。我包含的每个库（例如sqlx，等等）也有它自己的文件夹。src/  github.com/    jmoiron/      (sqlx package files)  example.co    my_app/      (my app package files)    model/      (model package files...)但是查看其他软件包，例如 sqlx，似乎他们完全废弃了这个目录结构并将所有文件放在根目录中这是因为我正在编写一个应用程序，而 sqlx 是一个旨在包含在其他应用程序中的包吗？还是只是偏好不同，因为没有真正公认的“标准”

Answer 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

)

Answer 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. 这样，您可以控制何时升级到较新版本的依赖项，并确保上游更改不会在您不知情的情况下破坏您的构建或以其他方式影响您的程序，直到您有机会进行彻底的测试。