service 层是否应该有通用的 crud 方法？

[jatesun]

今天跟 leader 产生了一点分歧， leader 认为 service 只应该包含业务逻辑方法而不应该有简单的增删改查方法，而我认为有时候 controller （或者 action ）只需要查看操作或者简单的删除操作， leader 认为如果有这种操作单独写 service 方法。大家有什么意见？

[mercurylanded]

一个是基于业务模型一个是基于数据模型.

从软件建模的角度来说你的 leader 是对的.

你把 crud 暴露出来了,是不是也把底层的 db 模型一起暴露出来了.

[zhenjiachen]

我自己写的项目都想放弃掉 service 了。

[jatesun]

@mercurylanded 但是每次遇到简单的难道都要写一遍→_→

[jatesun]

@zhenjiachen 有时候业务复杂还是很有必要的

[zhenjiachen]

@jatesun 对复杂的业务有必要，但是普通的 CRUD 完全没必要。我用 spring rest data ，直接把 repository 映射为 rest 接口。

[mercurylanded]

@jatesun 你不能保证简单的接口永远不会变化.需要单独写就说明这是另外一个业务了.当你把本来是多个业务去执行的东西塞到一个 crud 操作里去做之后.该需求的时候祝你好运.

[jatesun]

@mercurylanded 关键是通用方法不是特别容易变，只有业务借口才会容易变。

[jatesun]

@zhenjiachen 确实这样，简单的有个通用的的确很好

[zhenjiachen]

@jatesun 你们每个 service 都有接口么？我 service 从来不写接口。当然复杂的业务为了扩展有的地方是由调用者实现我定义的接口。

[slixurd]

不能跨层调用啊，再简单也不行

[mercurylanded]

@jatesun 你这个通用方法的定义本来都不对,把数据模型跟业务模型混起来了.

curd 是针对于数据模型去说的.没有包含业务,所以你看起来才是"通用"的.但是结合你的实际需求呢.

还有一个问题是直接暴露 crud 会把你的底层数据模型也曝露出来.如果有另外的系统要使用你这个接口耦合度就上去了.一个修改就可能影响多个系统.

当然如果你觉得不会有这些问题.写出通用的 crud 能大幅加快进度也没啥.写代码都是结合实际嘛..

[huyi]

所以他是你 leader

[ljbha007]

可以有增删查改的方法 但不需要通用的

[eecjimmy]

要分就彻底，否则就成那是看心情了，其他同事，或者后来的人，或者隔了两年，谁也不知道这段代码哪天写的，更不知道写代码人的心情如何？

[domty]

通用的 crud 不是应该放在 dao 里面的吗？
我很好奇你把通用的 crud 扔到 service 里，你 controller 和 dao 是怎么用的。

[Mac]

CRU 没什么问题，关键是 D ，是真的 D 还是 U 的变种。真的 D 不建议在 service 层面，这个隐患太大。

[SmiteChow]

你的领导是对的， CRUD 一般是放在 model 层次上做的。