理解分层架构之写出可维护性高的代码

300 阅读3分钟

前言

要写出可维护性高的代码有很多方法论,理解分层架构思想的精髓是写好可维护性高的代码的方法之一。分层架构的思想其实就是单一职责思想的延伸,各个层次的逻辑代表不同层次的抽象,且各个层次的抽象各司其职,不同层次的逻辑从上往下单向依赖,最终构建出完整的软件系统。最常用的分层架构是三层架构,也就是界面层业务逻辑层数据访问层。现在比较流行的架构是DDD架构,跟三层架构相比,多了一个领域层。每个层还可以继续细分出更多更小的抽象层次,java项目的每个包路径就是代表着每个层级的抽象。我相信很多人都比较熟悉分层架构的思想,但是往往在写代码的过程中逐渐偏离了其初衷。在此,我想讲一下我们实际开发过程中需要主要的问题,通过避免一些问题去写好可维护性高的代码。

相同抽象层不要互相依赖

同级别的抽象层,不要互相依赖,可以出现单向依赖,他们之间最好保持独立,没有依赖关系最好。当同层之间出现依赖的时候,要注意一下,业务对象之间的职责是否清晰。比如出现service1s1m1方法依赖service2s2m1方法,service2s2m1依赖service1s1m2方法的情况,service1service2就有着互相依赖的关系。这说明service1service2关系很密切,可以考虑把service1service2合并成同一个service,或者考虑把service2s2m1方法移到service1,也可以考虑把service2s2m1方法或者service1s1m2方法单独抽到一个独立的service中去,这样就解决了同层业务对象互相依赖的问题。同理,factorydao等其他抽象层也一样,避免设计出互相依赖的对象关系。

不同抽象层只能由上而下方向依赖

比如service层作为上层,他可以依赖dao层,而dao层作为下层,他不能向上反向依赖service层。而dao层可以往下依赖mybatis-plus底层接口,mybatis-plus可以往下依赖mybaitsmybatis可以往下依赖JDBC

不同抽象层之间的边界要清晰

在开发过程中很容易出现不同抽象层的代码互相侵入的情况,比如:
1)直接在service层继承mybatis-plusIService接口,或者在service层调用mybatis-plusIService接口,这都算是dao层的实现逻辑入侵到了service层;
2)在dao层的实现做了service层该做的逻辑,而不是单纯的数据库操作,这是service层的逻辑入侵到dao层了。
3)serviceDTO直接传到dao层,作为dao层的入参,或者dao层的返回参数直接使用service层返回给controller层的DTO,这都算是service层代码入侵到了dao层。dao层要定义自己的参数模型,service调用dao层时需要做参数转换。

总结

既然我们对分层架构都那么熟悉,我们在开发过程就要时刻注意,不要使自己的代码随着项目的复杂度增加而变质。