如题，而且项目的业务逻辑一般是写在那个层里面？ 这些有比较完善的规定么？ 还是自己随便定？
在controller调dao其实也没问题,你还是没搞明白为什么要分层,在规范上来说,dao层只处理与数据库的交互,说白了就是怎么访问数据库,比如查询返回list,map.update,delete之类的,总体来说dao层几乎都是固定化的东西,整个框架可以只用一个dao接口和实现类(前提是你知道泛型),整个service层都调用同一个dao,因为访问数据库就那么几个需求.
service层又叫做业务层,本来组织sql之类的都是在这层写,但是很多人会写在dao层,其实是不对的,但是也没人会在意,而且直接写在dao层会看起来简单,实则从长久看会麻烦,但是谁会在意呢,这只是个注重效率的时代,service层的目的是重用,就比如你要分页查询,就会分为3个方法,查list,查数量,和一个把这两个组装的方法,这样分页的时候直接调用组装这个方法就可以了,其他地方要查list或者数量就可以调另外的方法,要是把这个都现在一个dao中那就只专用于查询这个分页了,所以从长久来说在service层写sql是很有必要的(但是时间有时候不能让你思考那么多),再有一个就是service是受数据库事务控制的,就比如你一个请求要改变两个表的数据,那在service层调用两次dao就可以了,如果在controller调用两次service那第一次成功第二次失败了是不是还要回滚第一次的改变?
controller 主要是处理一些不想关业务的逻辑,就比如你人员表中存的人员所属部门的id,你现在不可能把id直接显示到页面上,但是又想少些sql和少的代码,那你就可以差分页之后,再在controller中调用查部门的service,这样把分页查到的list遍历一下就可以把按id把部门插进去,这样的好处是你人员的查询service中的sql只关心人员表的数据,不用各种关联其它表(但是有时候还是需要关联的).
就说这么多吧,纯手打,第一次打这么多东西....
service层又叫做业务层,本来组织sql之类的都是在这层写,但是很多人会写在dao层,其实是不对的,但是也没人会在意,而且直接写在dao层会看起来简单,实则从长久看会麻烦,但是谁会在意呢,这只是个注重效率的时代,service层的目的是重用,就比如你要分页查询,就会分为3个方法,查list,查数量,和一个把这两个组装的方法,这样分页的时候直接调用组装这个方法就可以了,其他地方要查list或者数量就可以调另外的方法,要是把这个都现在一个dao中那就只专用于查询这个分页了,所以从长久来说在service层写sql是很有必要的(但是时间有时候不能让你思考那么多),再有一个就是service是受数据库事务控制的,就比如你一个请求要改变两个表的数据,那在service层调用两次dao就可以了,如果在controller调用两次service那第一次成功第二次失败了是不是还要回滚第一次的改变?
controller 主要是处理一些不想关业务的逻辑,就比如你人员表中存的人员所属部门的id,你现在不可能把id直接显示到页面上,但是又想少些sql和少的代码,那你就可以差分页之后,再在controller中调用查部门的service,这样把分页查到的list遍历一下就可以把按id把部门插进去,这样的好处是你人员的查询service中的sql只关心人员表的数据,不用各种关联其它表(但是有时候还是需要关联的).
就说这么多吧,纯手打,第一次打这么多东西....
温馨提示：答案为网友推荐，仅供参考
第1个回答 2018-10-12
首先我们先知道spring的项目分层：
按照MVC的设计理念来讲，由service服务层调用持久层dao，在由controller调用service，这符合MVC的分层结构也符合我们的编程习惯。
dao一般是做封装，service做业务，controller校验数据
要是controller直接调用dao的话，controller直接拿到数据这是不安全的，而且平常的一些业务逻辑处理不好处理，因为业务需求是实时改变的，把业务写在dao里还要全部更改业务信息，这样不仅不会节约成本还增加耦合，代码复用性也不高后期代码维护也困难。建议还是遵循MVC分层结构开发，尽管是少量数据也不建议直接调用dao。关于好处可以上别人博客借阅：
第2个回答 2019-02-04
Controller层：负责具体业务模块流程的控制，即调用Service层的接口来控制业务流程。负责url映射（action）。
Dao层：负责数据持久化，与数据库进行联络的任务都封装在其中，Dao层的数据源以及相关的数据库连接参数都在Spring配置文件中进行配置。Dao接口中的方法都大同小异，因为对数据库的基本操作类似：insert、delete、update，select。 在Dao层定义的一些方法，在Service层并没有被使用的情况：Dao层的操作经过抽象后基本都是通用的，在Dao层完成相关方法的定义，有利于支持后期Service层的扩展。（与相应的mapper对应）
Entity层：java对象，与数据库表一一对应，是其对应的实现类。即一个Entity就是对应表中的一条记录。
Service层：建立在DAO层之上，Controller层之下。调用Dao层的接口，为Controller层提供接口。负责业务模块的逻辑应用设计，首先设计接口，再设计其实现的类。
View层：表示层，负责前端jsp页面表示。
原因:
面向接口编程。表示层调用控制层，控制层调用业务层，业务层调用数据访问层。
Dao层设计与设计的数据库表，和实现类（对应的Entity或者JavaBean）一一对应。
View层与Controller层结合紧密，需要二者结合协同开发。Service层、Dao层和其他层次耦合很低，完全可以单独开发。
Dao层：负责数据持久化，与数据库进行联络的任务都封装在其中，Dao层的数据源以及相关的数据库连接参数都在Spring配置文件中进行配置。Dao接口中的方法都大同小异，因为对数据库的基本操作类似：insert、delete、update，select。 在Dao层定义的一些方法，在Service层并没有被使用的情况：Dao层的操作经过抽象后基本都是通用的，在Dao层完成相关方法的定义，有利于支持后期Service层的扩展。（与相应的mapper对应）
Entity层：java对象，与数据库表一一对应，是其对应的实现类。即一个Entity就是对应表中的一条记录。
Service层：建立在DAO层之上，Controller层之下。调用Dao层的接口，为Controller层提供接口。负责业务模块的逻辑应用设计，首先设计接口，再设计其实现的类。
View层：表示层，负责前端jsp页面表示。
原因:
面向接口编程。表示层调用控制层，控制层调用业务层，业务层调用数据访问层。
Dao层设计与设计的数据库表，和实现类（对应的Entity或者JavaBean）一一对应。
View层与Controller层结合紧密，需要二者结合协同开发。Service层、Dao层和其他层次耦合很低，完全可以单独开发。
第3个回答 2018-10-25
一般来说，controller层是负责接收外部请求的，它的职责就是解析请求参数，根据参数判断要做哪些事件。但是它里面没有逻辑性。而Service层是负责处理业务逻辑的，主要是解决做什么，怎么做的问题。而dao是只负责和数据库打交到，把数据库的具体实现隔离开来。
这种设计的好处就是职责分离，修改各自的部分不会影响其它部分。比如controller层，一开始你使用的是json格式输入，但是以后想修改为protobuf，只需要修改这一个地方就行了。而service层，比如这个项目你是给A公司做的，现在B公司也要做一套差不多的，但有一些不一样的，你只需要把service层替换一下或继承一下就可以了，不会影响其它的。而Dao层，比如你现在使用的是mysql，将来公司有钱了，要换成oracle，只需要修改这一层就可以了。
想想，如果controller里面即做业务，又调用数据库，所有的东西都在一起，代码会非常混乱的。
这种设计的好处就是职责分离，修改各自的部分不会影响其它部分。比如controller层，一开始你使用的是json格式输入，但是以后想修改为protobuf，只需要修改这一个地方就行了。而service层，比如这个项目你是给A公司做的，现在B公司也要做一套差不多的，但有一些不一样的，你只需要把service层替换一下或继承一下就可以了，不会影响其它的。而Dao层，比如你现在使用的是mysql，将来公司有钱了，要换成oracle，只需要修改这一层就可以了。
想想，如果controller里面即做业务，又调用数据库，所有的东西都在一起，代码会非常混乱的。
第4个回答 2018-11-22
设计dao层的目的是为了crud方法接口话，方便实现方法，默认的开发模式就是这样，而service才是真正的执行者，这样的实现方式是为了将事务处理最小单元化，方便管控，将数据传给controller才能真正的消费数据，因为controller层一般是不可以事务处理的，原因是，如果controller实现了接口，那么就spring就不会对其进行代理（其实是代理了，但是走了jdk代理，没有使用cglib），这样就不存在aop对其声明式事务了，如果没有实现接口，那还好办，可以实现事务处理，而且大多数的spring都不是独立开发，基本上都要结合mvc等手法，那么在不同的application扫描的时候呢，容易多重扫描和功能覆盖扫描，这样的话，导致service层也不存在事务处理了。
还希望能帮到你，望采纳
还希望能帮到你，望采纳
