新手提问：Golang Go语言中 gin+gorm 中大型项目分层问题
新手提问：Golang Go语言中 gin+gorm 中大型项目分层问题
最近在看 gin，感觉对中大型项目的结构规划有点模糊。
在 github 上看了一些例子，按我现在的理解分层：
controller – 请求入口，参数校验，调用 server，返回错误或响应
server – 接收已验证参数，实现具体业务逻辑，调用 dao，返回结果
dao – 所有与数据库相关的操作
model – 定义 struct 以用于 orm 映射
不知道我的理解是否正确，同时，我还有下面一些疑惑：
1：dao 层的作用？我在网上看的例子有一些有 dao 层，同时也有很大一部分没有这层，server 层的代码中直接调用 orm 增删改查的方法。如果 server 中每次要用到数据库的地方甚至只是参数稍有不同，就要在 dao 中写一个对应的函数，岂不是会很繁琐。而且我觉得对于像 CreateTag 这种简单方法，orm 也是直接一行语句就能实现，再单独包 dao 这一层他的优势是什么。
2：server 层的写法？我现在的理解是有几个 controller 就要写几个对应的 server，比如有 CreateTag, ListTag, UpdateTag, DeleteTag, CreatePost, ListPost, UpdatePost, DeletePost 这 8 个 controller 是不是就要写 8 个对应的 server，那拆分出 server 层的目的仅仅就是不让业务逻辑都堆在 controller 吗，我在网上有看到说 server 层可以重用代码，但这样每加一个 controller 就要加一个 server 的，该怎么体现重用
刚看完代码，脑子有点乱，还希望有大神能解答我的疑惑
更多关于新手提问：Golang Go语言中 gin+gorm 中大型项目分层问题的实战教程也可以访问 https://www.itying.com/category-94-b0.html
请把 Java 那套坏习惯改掉吧，go 不适合这套
更多关于新手提问：Golang Go语言中 gin+gorm 中大型项目分层问题的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html
不要什么都带入 java，要这么写用 java 不好吗
go 的大多数人认可的项目规范：
https://github.com/golang-standards/project-layout
谢谢回复，我没写过 JAVA，我之前用 python/flask 写小项目的时候是最简单的只分了 model 和 controller，但我感觉对于大型项目，这样可能不太好，所以现在转到 go 希望能找到更好的项目结构方案。
go 比较随意，写 web 项目我一般开 config, engine, httphandle, service, storage 几个目录，也不绝对，根据项目来，网上有一些建议的目录组织方式，找一个适合自己的就行，项目写多了，就能找到一个比较合适自己的了
dao 还是要有的，未来如果需要在 data load 这个切面做事情的话，没有单独分层而是“server 层的代码中直接调用 orm 增删改查的方法。”会导致改起来很麻烦。当业务大到一定程度就没法改了。
其实如果还处于对性能要求不高的阶段，dao 层可以很简单，只有 list 、load 、save 三个方法。
至于 controller 和 service，我觉着确实一定程度上可以合并。现阶段大部分写事务脚本的业务，service 复用的机会不多。能复用的话也都会抽成单独的子函数。
建议楼主实践下 ddd，代码写出来会很清晰。
建议楼主不要按 java 的写法就被打成反 java 和喷楼主，我是服了
我想没几个开源大项目的 go 或者 python 按照这样写的
只是觉得语言的特性不同，有时套着写会显得很累赘
谢谢回复！我还想请教一下有关 dao 层的问题：1.如果后续项目除了 mysql 还要用到 mongodb 或者 redis 的话，是不是相关操作也都放在 dao 层。2.dao 层里具体实现是对每一个 model 都要写自己的 list 、load 、save 函数吗，而且对与 list，我可能会有好多地方用到，但参数条件可能都不同，比如有些要多个 where，有些要 order by，有些要 limit，这是不是每用到一个不一样的，虽然都是 list，但都要再加一个函数？
1. 都放在一层 dao 里，叫什么不重要，重要的这层只负责数据的加载和保存，你只需要调用标准接口，不需要关心存储细节；
2. 从 DDD 的角度来讲，每一个聚合根对应一个 DAO （ DDD 里叫 repository ）。但如果只从分层角度来考虑的话，是的，每一个 model 对应一个 dao ；
3. 对于 list 接口，你自己已经提到了，where/order by/limit 都只是“参数条件”，所以他们只是一个大接口的参数而已，这个接口的基础功能，就只是 list，至于怎么 list 、list 多少个东西出来、顺序是啥样的，只是参数而已
上面有些人是不是有点偏激啊，不清楚这样分层有啥大毛病，MVC 从来就不是 Java 的专利和代名词…为啥称之为“Java 的坏毛病”？再说论工程化的话，Java 有很多东西是 Go 要学的，我虽然喜欢 Go，但是真不想和这群人为伍
在Golang中使用Gin和Gorm构建中大型项目时，合理的分层架构对于提高代码的可维护性、可读性和可扩展性至关重要。以下是对分层问题的一些建议：
- 表现层（Handler层）：主要负责处理HTTP请求、解析和验证输入数据。使用Gin框架来构建HTTP服务器，并定义路由，将不同的URL路径映射到对应的处理函数。
- 业务逻辑层（Service层）：包含项目的核心业务规则和操作。处理从表现层接收到的数据，进行业务逻辑处理，如数据的计算、业务规则的验证和业务流程的控制。
- 数据访问层（Repository层）：负责与各种数据存储（如数据库）进行交互，包括数据的读取、写入、更新和删除操作。使用Gorm框架来简化数据库操作，并定义数据访问接口和实现。
此外，还可以考虑增加以下层次：
- Domain层：定义业务领域的实体、值对象以及业务逻辑规则，确保业务逻辑的纯粹性和一致性。
- Infrastructure层：提供项目运行所需的基础设施服务，如数据库连接、缓存、消息队列、日志记录等。
在实际项目中，根据具体需求合理应用分层结构，确保代码的清晰性和可维护性。同时，注重单一职责原则和依赖倒置原则，使各层次之间的依赖关系更加清晰和稳定。
