Golang 写的 web 也分 Service 和 DAO 吗?

[chaleaoch]

python 后端出身.

第一次写 go web. 然后照着网上的开源项目抄. 我觉得 controller service Model 三层还是可以的. 毕竟业务扔到 Service 里面逻辑更清晰一些.

然后和 Java 同事请教了一下. 令我困惑的是:

• 类似验证密码的操作, 也要放到 Service 里面取做. 之前 django 的写法就是

user_instance.check_passwork(request.Post['password']) 

这样不行吗? 为什么一定要

1. get password from DB
2. checkpassword with request

---

• Service 里面不要出现 SQL. 也就是说, 所有的查询都要用 Dao 转一手. 譬如我要查询一个用户是否存在. 如果用 Gorm 的话

DB.Where(map[string]interface{}{"user_id":666}).Count(&count)

这句话必须放在 DAO 层, 而不是直接在 Service 里写? 感觉好麻烦啊.

我的问题是:

1. GO 可以更灵活吗? 更灵活一些是套路吗? 在开源项目中 / 实际商业项目中有成功案例吗?
2. Java 分这么多层是 JavaEE 带进来的还是 Spring 带进来的? 还是谁带进来的? 没人提出过异议吗?

谢谢

[hihanley]

@rimutuyuan 我也想学习一下，兄弟有地址吗

[libook]

这个问题不应该是 XX 语言要不要写 DAO，而是当前的项目情况上来评估加一层 DAO 是否有收益。

Java 的开发者群体是极其庞大的，也同时是良莠不齐的，很多水平不高的 Java 工程师习惯在各种项目上套用相同的架构，真正的架构师回去评估系统特点以及架构设计上的收益和成本。

架构上的思想都是工具，能在特定场景解决特定问题，所以不管用什么语言、框架，只要觉得某个架构思想适合用来解决问题，就可以拿来用。但同时，工具不是用来制造问题的，所以如果用起来会徒增成本，那么就没必要硬上。

[soupu626]

@chaleaoch DAO 不带业务，就是对单表的数据查询访问，如果想要一个数据层的简单业务封装，比如逻辑删除、不可见订单的过滤，多表的数据查询聚合，我们组的做法是，会抽一层 manager 出来，如果是专职数据访问的 manager，有时候会命名为 DAC
service 之下 dao 之上再区分一层 manager 出来，在有些情况下可以提高内聚性，还是具体问题具体分析，当然如果有公司或者组内规约，还是按规约来，不然也许哪天被人在注释里一顿狂喷。。。

[zjsxwc]

写 java 时会有 dao 层我个人认为是受了 mybatis 的影响，用了 mybatis 那些 xml 或者 注解 非原生代码 方案的，你是不得不用 dao 层，君不见 springboot 的 jpa 方案就没有 dao 而是用了 repository 模式， 因为 repository 是原生代码实现所以甚至可以在 repository 里注入别的业务对象，而 dao 的 xml 或者注解都只是文本字符串，根本不能注入原生语言的对象，于是迫不得已，只能在套个 dao 对象来搞良。

题外话，绝大部分项目没有切换数据库如 mysql 换 pg 的需求，
有很小很小部分项目有换 orm 轮子的需求，比如 beego 自带的 orm 换 gorm 。

[sanyuedev]

个人觉得 DAO 可以去掉

[wangbenjun5]

一般 controller 、service 、model 3 层，model 就是 db 层，负责和数据库交互，这个少不了。

service 层的话，其实很多简单的业务确实多余，用不上，硬是搞这一层闲的繁琐，其实可以去掉！

[chaleaoch]

@zjsxwc 谢谢大佬, 你这个回答好.

[sujin190]

java 感觉逻辑就是，分层、结构、解耦、扩展好维护，要考虑流量上来了团队壮大了如何如何，结果现实情况加班加点做完每三个月项目黄了，其实光是上半年就倒闭了数十万家公司，能做起来的少之又少，想这么多都是有的没的，特别是 mybatis 这一套，小公司使用场景来看设计的简直神经病一样的，所以依据自己现实和工程方法，选择合适的方案就可以了，没必要硬套这些东西

[yrj]

我的方式，直接 gorm 写 service 里，不用 dao 。

[zand]

@kxiaong 赞同，python 不背这个锅，使用 Django 的项目也应该有良好的分层，一味求简单只是给后来人挖坑。
比如需要分库分表时，满山遍野的 objects 真的让人崩溃。

[fiypig]

分控制层跟模型层

[chaleaoch]

@zand 但是在开源项目里. 我没见过像你说的那么用的啊. 你有例子吗? 我学习一下.

[chaleaoch]

@yrj 和我想的一样 默认我也想这样用.

[forbreak]

分不分层是自己决定的，跟语言无关，跟工程化有关。实际项目你想咋写咋写，没有语言会限制你。

[anonydmer]

楼主先前 django 写那个密码验证没有写单元测试吧

[jetyang]

楼主说到 java web 程序员的痛处了

[anonydmer]

忍不住想说两句

1. DAO 是个很古老的东西，不是伴随 mybatis，hibernete 这些产生的；事实上，早在 EJB 时代就有它了
2. DAO 全称是 Data Access Object， 不是 Database Access Object ；所以把它狭隘的理解成适配多个数据库是不好的；事实上，这一层可以从数据库获取数据，也可以从文件系统获取数据，还可以从网络远程获取数据；
3. 除了适配不同持久层之外，DAO 还有个重要的作用的是做持久化数据和模型直接的转换，比如存储字段和模型字段的差异，一些特殊格式的处理；这也是在实际工作中经常需要用到的

至于用不用 DAO 或者类似 Repository 这一层，如果说项目只需要考虑一个数据库，没有任何模型和存储的格式差异，很多人选择不要这一层；不过咱们可以不用，但是得知道为什么不需要用。 不过我相信没用这一层的同学，大多数业务层代码肯定没有写单元测试吧。

[basefas]

@hihanley #20 对的，所以项目中，internal 包是全局可以访问的，但是当别人 import 你的项目时，就不能调用 internal 中的方法，如果你不在意这些，就完全可以不用这个命名，起个你喜欢的名字

[cslive]

工程规范而已，java 你可以直接在 jsp 里写，全部业务逻辑，sql，html，js 都在 jsp 里写，这样我估计你自己也不想看

[ElmerZhang]

项目小了怎么写都行，项目大了要找适合这个项目的写法。写 web 服务或者 api 服务，controller service Model 三层结构的适用性是最广的，但并不一定适用于你的项目。
先写吧，写着写着可能就会发现怎样怎样写更好一些，然后再重构呗。
我个人经验经验是这样的：某个 model 自身有些特定逻辑，并且在多个 service 中都会用到，那么可能需要抽出一个 dao 层来做。
另外如果针对 model 有缓存的话，service 和 model 之间可能也要加一层，叫 manager 之类的。
简单来说，当你在同一层的多个文件中经常 copy&paste 代码的时候，就要考虑提出一层或者提个 util 出来了。