vlambda博客
学习文章列表

企业开发spring框架业务逻辑复用的两个技巧

spring 框架是企业开发最常用的框架,以其高度可定制、可扩展性著称。

典型的 spring mvc 分层架构中,会形成 Controller、Service、Dao 三层。这三层的类实例都会作为 bean实例注册到 spring 的 bean 容器中。

Service 层是非常重要的一层,集中了大量的业务逻辑。普通情况下还好,但是如果你在开发的过程中,遇到有一组 Service 要共用业务数据处理逻辑,但是处理过程又有某些细微不同,这个时候你怎么办?

一般工程师懒得设计的话,就直接将业务数据处理逻辑都在每个 Service 中实现了。但其实有两个常用的技巧去处理这种场景,一个是抽象模板类,另外一个是策略模式。

抽象模板类中一般有个模板方法,封装了数据处理逻辑的模板方法。模板方法会调用类中定义的抽象方法。而这些抽象方法会在继承模板类的子类(Service )中个性化定制实现。使用子类 Service 的实例,就可以直接调用模板方法了。这种技巧采用了类继承方式。

而策略模式采用的是类组合方式。策略模式主要有两种类,Context类和Strategy类。Strategy接口的实现会作为Context类构造函数的参数。你很容易想到,要复用的数据处理逻辑应该放到Context类的public 方法中,而个性化处理会作为Strategy的接口方法。Context类的数据处理方法会调用Strategy的接口方法。

Strategy接口对应到 spring mvc 中,可以是 Service 接口。在阿里巴巴java 项目分层规范中,除了 Service 层,还有一个 Manager 层,主要职责是 Service 层的一些通用能力下沉。你可以将Context类的实现放到 Manager 中,供那一类Service使用。

这两种业务逻辑复用技巧,我都有在实际项目中用过。但是相对而言,比较喜欢使用策略模式。它是基于组合的方式,比基础方式更灵活一些。