十年网站开发经验 + 多家企业客户 + 靠谱的建站团队
量身定制 + 运营维护+专业推广+无忧售后,网站问题一站解决
首先解释面上意思,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层只是负责传递一些数据进去接受返回的结果和选择跳转页面而已