Service层和Dao层一定要对应吗？

Question

我习惯于根据逻辑调用Dao，不喜欢Service和Dao一定要一一对应

Answer 1

对应不对应都可以。
对应：即，一个service配一个dao，高内聚，体现了一个类即一个服务的思想，虽然夸了层，放在不同的类，但是从上到下浑然一体，与其他dao没有任何交集，是现在新产生的一种思想，缺点是代码量会大一点。
不对应：即，一个service可以配若干个dao，这是基于传统三层的架构演化而来，dao层的代码复用性高，说白了还是三层思想，不体现高内聚的原则，但是代码量会小很多，利于维护。

Answer 2

没太明白你说的逻辑调用是什么模式。。。。按照我的理解其实没什么不可以，但相比较之下按照模块对应要比按照逻辑对应清楚的多。
1.开发：一般开发时候分工都是按照模块分工的，举个简单的例子：比如A负责产品模块，B负责订单模块，C负责支付模块，D负责用户模块……如果你是说的按照逻辑，我理解是让A做所有的查询，B做所有的修改，C做多有的增加，D做所有的删除？因为项目已开始各自回创建个字的文件Dao和Service？这样比如修改的会用到查询，这个模块是两个人同时做的，那么并行任务就会变成串行任务，或者会出现大量重复代码。
2.部署：如果是分模块开发，每个模块的功能都是完整的，可以分布式部署成RPC模式，我只要通过远程调用就好了，哪一个模块处理问题，那个服务除了问题，我可以很快的更换哪一个模块，能最少的影响其他模块，比如订单服务坏掉了，用户还可以登陆，修改自己的信息等等。如果按照逻辑当然你也可以分布式不是，但是一台服务有问题了，比如说复杂查询的服务坏掉了，那么你连登陆都登陆不了。
3.维护：如果后期升级，加入要改成单点登录的模式，按照逻辑几乎所有文件都要更新。但是按照模块的的方式能最少的减少更新。对系统的影响是最小的。

其实我不太确定你说的逻辑调用是什么模式，一般也不一定非要对应，但基本都是按照一个模块来的。

Answer 3

不需要一一对应 分层只是为了重复的业务能直接调用 上层可以随便调用相关的下层逻辑，
例如我的service主要是用来处理订单 我取名叫OrderService service主要的业务是通过操作order实体来实现的也就是说我会注入一个OrderDao这样的数据操作接口来处理订单，但是我发现我需要对处理过的订单添加日志记录之类的处理我可能就需要注入一个LogDao的接口来掉相关的数据操作方法

Answer 4

规则是定的 但是工作中你会发现 有些不一定非要一一对应 灵活运用就好了