前言
要写出可维护性高的代码有很多方法论,理解分层架构思想的精髓是写好可维护性高的代码的方法之一。分层架构的思想其实就是单一职责思想的延伸,各个层次的逻辑代表不同层次的抽象,且各个层次的抽象各司其职,不同层次的逻辑从上往下单向依赖,最终构建出完整的软件系统。最常用的分层架构是三层架构,也就是界面层、业务逻辑层、数据访问层。现在比较流行的架构是DDD架构,跟三层架构相比,多了一个领域层。每个层还可以继续细分出更多更小的抽象层次,java项目的每个包路径就是代表着每个层级的抽象。我相信很多人都比较熟悉分层架构的思想,但是往往在写代码的过程中逐渐偏离了其初衷。在此,我想讲一下我们实际开发过程中需要主要的问题,通过避免一些问题去写好可维护性高的代码。
相同抽象层不要互相依赖
同级别的抽象层,不要互相依赖,可以出现单向依赖,他们之间最好保持独立,没有依赖关系最好。当同层之间出现依赖的时候,要注意一下,业务对象之间的职责是否清晰。比如出现service1
的s1m1
方法依赖service2
的s2m1
方法,service2
的s2m1
依赖service1
的s1m2
方法的情况,service1
与service2
就有着互相依赖的关系。这说明service1
和service2
关系很密切,可以考虑把service1
和service2
合并成同一个service
,或者考虑把service2
的s2m1
方法移到service1
,也可以考虑把service2
的s2m1
方法或者service1
的s1m2
方法单独抽到一个独立的service
中去,这样就解决了同层业务对象互相依赖的问题。同理,factory、dao等其他抽象层也一样,避免设计出互相依赖的对象关系。
不同抽象层只能由上而下方向依赖
比如service层作为上层,他可以依赖dao层,而dao层作为下层,他不能向上反向依赖service层。而dao层可以往下依赖mybatis-plus底层接口,mybatis-plus可以往下依赖mybaits,mybatis可以往下依赖JDBC。
不同抽象层之间的边界要清晰
在开发过程中很容易出现不同抽象层的代码互相侵入的情况,比如:
1)直接在service层继承mybatis-plus的IService
接口,或者在service层调用mybatis-plus的IService
接口,这都算是dao层的实现逻辑入侵到了service层;
2)在dao层的实现做了service层该做的逻辑,而不是单纯的数据库操作,这是service层的逻辑入侵到dao层了。
3)service层DTO
直接传到dao层,作为dao层的入参,或者dao层的返回参数直接使用service层返回给controller层的DTO
,这都算是service层代码入侵到了dao层。dao层要定义自己的参数模型,service调用dao层时需要做参数转换。
总结
既然我们对分层架构都那么熟悉,我们在开发过程就要时刻注意,不要使自己的代码随着项目的复杂度增加而变质。