如题，而且项目的业务逻辑一般是写在那个层里面？ 这些有比较完善的规定么？ 还是自己随便定？
第1个回答 2011-12-14
controller是对程序整体流程的控制，service是针对实体的操作类，获取数据的追问
那我的service基本上就是在做一个调用dao的过程。。。。 是为了以后业务需要操作许多的dao的时候，只改动service么？
第2个回答 2018-10-22
service层作用就一个，处理复杂的业务逻辑。
在比较大型的系统中，由于处理的逻辑很复杂，一次请求可能要多次操作数据库，而如果就把这些调用dao层的代码写到action中，可是可以，但是不利于代码的维护和可以复用性，所有一般都会在dao层和action中间加上一个service层，将一些复杂的逻辑交给service层处理。
在比较大型的系统中，由于处理的逻辑很复杂，一次请求可能要多次操作数据库，而如果就把这些调用dao层的代码写到action中，可是可以，但是不利于代码的维护和可以复用性，所有一般都会在dao层和action中间加上一个service层，将一些复杂的逻辑交给service层处理。
第3个回答 2018-11-14
面向对象编程，业务逻辑做在service层实现。dao层主要用来操作db，controller主要用来处理request调用不同的service方法。
再具体一点：controller主要是拿到请求实体VoReq，调用service方法后得到返回的RespVo给client端
service主要是完成业务逻辑处理，reqVo转化成数据库实体Po，或者Po转化成respVo.
dao层主要是直接操作DB
再具体一点：controller主要是拿到请求实体VoReq，调用service方法后得到返回的RespVo给client端
service主要是完成业务逻辑处理，reqVo转化成数据库实体Po，或者Po转化成respVo.
dao层主要是直接操作DB
第4个回答 2018-11-14
完美的架构就是controller只与前台做交互，不写业务逻辑
具体业务逻辑实现就放在service层，这样层次清晰，而且可以把service层可以注入到不通的controller，提高代码复用率，事物一般也配置在service
大的项目一般都遵循这个规则，提高代码可读性，，，，如果你非要把所有代码都写在controller层 系统也能运行 不会报错
具体业务逻辑实现就放在service层，这样层次清晰，而且可以把service层可以注入到不通的controller，提高代码复用率，事物一般也配置在service
大的项目一般都遵循这个规则，提高代码可读性，，，，如果你非要把所有代码都写在controller层 系统也能运行 不会报错
第5个回答 2018-11-16
面向对象编程原则：
单一职责原则
里氏替换原则
依赖倒置原则（高层模块不应该依赖低层模块）
接口隔离原则（客户端不应该依赖它不需要的接口）
迪米特法则（尽量降低类与类之间的耦合）
开闭原则（对扩展开放，对修改关闭）
理想的面向对象应该是高内聚低耦合的，之所以采用分层设计就是为了实现这一目标。
