首先解释面上意思，service是业务层，dao是数据访问层。
景洪网站建设公司创新互联公司,景洪网站设计制作，有大型网站制作公司丰富经验。已为景洪成百上千家提供企业网站建设服务。企业网站搭建\外贸网站制作要多少钱，请找那个售后服务好的景洪做网站的公司定做！
呵呵，这个问题我曾经也有过，记得以前刚学编程的时候，都是在service里直接调用dao，service里面就new一个dao类对象，调用，其他有意义的事没做，也不明白有这个有什么用，参加工作久了以后就会知道，业务才是工作中的重中之重。
我们都知道，标准主流现在的编程方式都是采用MVC综合设计模式，MVC本身不属于设计模式的一种，它描述的是一种结构，最终目的达到解耦，解耦说的意思是你更改某一层代码，不会影响我其他层代码，如果你会像spring这样的框架，你会了解面向接口编程，表示层调用控制层，控制层调用业务层，业务层调用数据访问层。初期也许都是new对象去调用下一层，比如你在业务层new一个DAO类的对象，调用DAO类方法访问数据库，这样写是不对的，因为在业务层中是不应该含有具体对象，最多只能有引用，如果有具体对象存在，就耦合了。当那个对象不存在，我还要修改业务的代码，这不符合逻辑。好比主板上内存坏了，我换内存，没必要连主板一起换。我不用知道内存是哪家生产，不用知道多大容量，只要是内存都可以插上这个接口使用。这就是MVC的意义。
接下来说你感觉service的意义，其实因为你现在做东西分层次不是那么严格，在一个你们做东西业务本身也少，举个最简单的例子，你做一个分页的功能，数据1000条，你20条在一个页，你可以把这个功能写成工具类封装起来，然后在业务层里调用这个封装的方法，这才是业务里真正干得事，只要没访问数据库的，都要在业务里写。
再有不明白的追问，这是经验问题，呵呵，其实以后你就会懂。只是刚开始写的代码都是有个请求，我就去数据库取，业务几乎没有。
烟囱式开发模式：
上述开发模式有几个弊端：
这样开发模式的优势：
业务代码集中在业务层 service,专注于业务对象 bo 的封装以及业务对象给展示层 vo的转换，封装复用逻辑，可以减少大量重复的代码，后期维护便捷的多。
数据库改动只设计dao层，快速响应各个业务。
业务代码如何拒绝 all in one
以上的controller代码最突出的缺点就是代码完全无法复用，完全没有使用到面向对象封装，集成，多态的特性。业务开发中，一般都是权限校验，参数校验，业务判断，业务对象转换数据库操作。
我的做法是业务抽象，把公共代码进行抽取，通过配置的形式的方式调用，使业务代码可以以可插拔的方式选择指定的权限校验，参数校验。简单来说，就是善用AOP面向切面编程的思想，示例如下：
使用aop对权限校验逻辑进行抽取，能够通过注解的方式指定哪些controller需要进行权限校验。对用户进行数据过滤时，使用controller的拦截器获取该用户拥有的各类权限，并把用户数据保存在上下文threadloal中，并且通过配置对指定url进行拦截。在业务层，从上下文拿到用户权限数据做各类数据业务过滤，通过aop实现各类拦截业务的指定调用。
使用java validtion对通用的字段，例如电话号码，身份证，进行扩展，详细可以参考，如何使用validation校验参数？，在项目中其他类似校验进行复用。
业务判断：使用设计模式对不同类型的业务开发进行封装，集成，多态扩展；这样在后期的扩展中可以基于开发封闭原则，针对新的业务扩展子类即可。
业务开发过程中，依照阿里巴巴研发规范的要求，存在DO(数据库表结构一致的对象)，BO（业务对象）,DTO(数据传输对象)，VO（显示层对象），Query（查询对象）。
使用MapStruct，可以灵活的控制的不同属性值之间的转换规格，比org.springframework.beans.BeanUtils.copyProperties()方法更加灵活。
例如，公共字段，生成日期，创建人，修改时间，修改人使用插件的形式进行封装，在mybatis-plus中使用MetaObjectHandler，在执行sql之前完成统一字段值的填充。
项目如何做好代码注释？
在业务中特别是状态的值，在对外发布api的vo对象中，加上状态枚举值的注释，并且使用@link 注解，可以直接连接到枚举类，让开发者一目了然。
Dao是封装数据库层操作的，写好了就基本不修改了，所以在封装的过程中注意必须提供最起码的增删查改方式，而且查比较重要，一般会提供分页查询
Service层是最繁琐的一层，也是最重要的一层，一切业务的复杂处理都在这层完成，你的web层只是负责传递一些数据进去接受返回的结果和选择跳转页面而已
