这是一个创建于 3064 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天跟 leader 产生了一点分歧， leader 认为 service 只应该包含业务逻辑方法而不应该有简单的增删改查方法，而我认为有时候 controller （或者 action ）只需要查看操作或者简单的删除操作， leader 认为如果有这种操作单独写 service 方法。大家有什么意见？
 |
1
mercurylanded 2016-07-08 17:20:00 +08:00
一个是基于业务模型一个是基于数据模型.
从软件建模的角度来说你的 leader 是对的. 你把 crud 暴露出来了,是不是也把底层的 db 模型一起暴露出来了. |
 |
2
zhenjiachen 2016-07-08 17:21:45 +08:00
我自己写的项目都想放弃掉 service 了。
|
 |
3
jatesun OP @mercurylanded 但是每次遇到简单的难道都要写一遍→_→
|
|
4
jatesun OP @zhenjiachen 有时候业务复杂还是很有必要的
|
|
5
zhenjiachen 2016-07-08 17:26:27 +08:00
@jatesun 对复杂的业务有必要，但是普通的 CRUD 完全没必要。我用 spring rest data ，直接把 repository 映射为 rest 接口。
|
|
6
mercurylanded 2016-07-08 17:26:34 +08:00
@jatesun 你不能保证简单的接口永远不会变化.需要单独写就说明这是另外一个业务了.当你把本来是多个业务去执行的东西塞到一个 crud 操作里去做之后.该需求的时候祝你好运.
|
|
7
jatesun OP @mercurylanded 关键是通用方法不是特别容易变，只有业务借口才会容易变。
|
|
8
jatesun OP @zhenjiachen 确实这样，简单的有个通用的的确很好
|
|
9
zhenjiachen 2016-07-08 17:36:34 +08:00
@jatesun 你们每个 service 都有接口么？我 service 从来不写接口。当然复杂的业务为了扩展有的地方是由调用者实现我定义的接口。
|
 |
10
slixurd 2016-07-08 17:51:35 +08:00
不能跨层调用啊，再简单也不行
|
|
11
mercurylanded 2016-07-08 17:59:42 +08:00
@jatesun 你这个通用方法的定义本来都不对,把数据模型跟业务模型混起来了.
curd 是针对于数据模型去说的.没有包含业务,所以你看起来才是"通用"的.但是结合你的实际需求呢. 还有一个问题是直接暴露 crud 会把你的底层数据模型也曝露出来.如果有另外的系统要使用你这个接口耦合度就上去了.一个修改就可能影响多个系统. 当然如果你觉得不会有这些问题.写出通用的 crud 能大幅加快进度也没啥.写代码都是结合实际嘛.. |
 |
12
huyi 2016-07-08 18:03:45 +08:00
所以他是你 leader
|
 |
13
ljbha007 2016-07-08 18:09:16 +08:00
可以有增删查改的方法 但不需要通用的
|
 |
14
eecjimmy 2016-07-08 18:41:38 +08:00 via iPhone
要分就彻底，否则就成那是看心情了，其他同事，或者后来的人，或者隔了两年，谁也不知道这段代码哪天写的，更不知道写代码人的心情如何？
|
 |
15
domty 2016-07-08 20:16:17 +08:00
通用的 crud 不是应该放在 dao 里面的吗？
我很好奇你把通用的 crud 扔到 service 里，你 controller 和 dao 是怎么用的。 |
 |
16
Mac 2016-07-08 20:34:17 +08:00
CRU 没什么问题，关键是 D ，是真的 D 还是 U 的变种。真的 D 不建议在 service 层面，这个隐患太大。
|
 |
17
SmiteChow 2016-07-09 16:21:41 +08:00
你的领导是对的， CRUD 一般是放在 model 层次上做的。
|
Select Language