关于自己对 Go web 的包结构理解

[Cola98]

不同语言的项目结构都不太一样的，就像 MVC 并不是 Java 的专属，但是现在提到 MVC 大家都会提到 Java ，从而到 spring/spring Boot 。

这里推荐一个项目结构，它并不是 golang 官方的标准，再加上阿里的 Java 开发手册，如下所示:

• cmd: 主要是各种功能的入口，简单来说像 main.go 就可以放到这里。
• internal(内包是不希望其他人在其应用程序或库中导入代码)
  • db: 数据库相关的配置。
  • dao: 和数据库交互的都可以放在这里，我把 CRUD 之类的都放在这里了。
  • model: 和数据库表对应。
  • service: 具体逻辑实现。
  • dto: 放一些和前端交互的参数
  • controller: 做一些校验。
• pkg: 外部应用程序可以使用的库代码，其他项目会导入这些库。
• vendor: 这里就根据版本来了，一些老的 golang 项目还会有，存放一些第三方库，到后来 go mod 的出现这个就不需要有了。

像 internal 这种就可以根据自己的需求来，我是参考了阿里的 Java 开发手册还有之前在上海实习的时候的项目结构。

这是我写的博客中一部分，附上博客链接( https://shuimo03.github.io/)

[cooper]

挺好，建议 controller 改为 handle 。

[ychost]

GO 就不要搞 Java 的结构了，太啰嗦

[Cola98]

@cooper 嗯嗯，之前主要是习惯了

[Cola98]

@ychost 嗯嗯，也是参考了一些别的项目，发现像 Java 的比较多一点，但是这样写起来心智负担比较大

[charmToby]

model 和 dao 层我感觉可以放一起

[fiypig]

db 可以改成 config 因为不单单是 db, 其实 go 最方便就是自己造,随便弄,过于约束也很麻烦

[panlatent]

赞同 #2 的，目录结构多花心思搞 多设计下没毛病，但是类似 Java 之类的结构，拿到了 Go 是真的水土不服。

[dacapoday]

如果是小型 web 程序，这种结构太沉重了。java 是历史原因导致的，但 go 没有这种包袱。

[dacapoday]

@dacapoday go 的关键词比较少，表达能力不如 java ，采用 java 的这种结构会多很多代码。让 go 的开发效率像 java 一样低效，费人力。

[sadfQED2]

dao 和 model 可以合成一个，两个比较冗余，但问题也不大

controller 和 service 中间还应该加一层，因为 service 之间不能互调，互调的业务逻辑放到 controller 中也不合适

[zhangzEric]

OP 博客里很多没完成的文章啊，本来抱着探索的希望进去，好几篇都是写一半空一半，建议 OP 后续有空填一下坑😂

[coolair]

这种结构真没必要用 Go 了，直接用 Java 不香吗？

[qW7bo2FbzbC0]

- adapter
- model
- controller
- service/repository
- helper

[sciel]

/
├── api
├── internal
│ ├── cmd 入口指令
│ ├── consts
│ ├── controller
│ ├── dao
│ ├── model
│ └── service
├── manifest 配置文件
├── resource
├── utility 通用工具
├── go.mod
└── main.go

我觉得这个就挺好，来自 goframe

[LoNeFong]

https://github.com/golang-standards/project-layout

[keepeye]

goframe 的分层设计可以参考一下

[freakxx]

@sadfQED2 #10

这个其实是我一大难受的地方，不知有没比较好的处理方式。

比如
A service 需要 调用 B service 的某一个 func
B service 反过来可能需要用到 B service 的 func

抛上一层后，还是解决不了循环引用的问题，总感觉不够直觉性。
然后这里就会开始变得有点脏，要么是冗余，要么就是需要做一些繁琐的处理。

[sadfQED2]

@freakxx #17

所以 controller 和 service 之间应该加一个业务逻辑层呀，专门用来调多个 service

[blless]

要我说不如 DDD 。写到很多复杂业务的时候，无脑 controller 其实发现很多代码不知道放哪里，最后又都放到 controller 里，分了其实最后也没怎么分。DDD 从开始会让你拆分业务领域，持久层跟表现层其实都不是业务的重点。

[freakxx]

@sadfQED2 #18
是这么说，但就像#19 说的，业务代码膨胀后，代码有时会有些不知放哪，挺烦恼的事情