零配置Spring框架设计之模块化原则

我就是我 2022-05-29 12:51 143阅读 0赞

Spring以其强大的拓展性 很多时候被用来作为项目框架的基础，来整合其他的框架。网络上Spring整合其他框架的资源很多，实用的时候只要引入相应的jar包，然后添加一两行代码就能实现整合，比如整合Kafka，添加一个@EnableKafka；整合Rabbit，添加@EnableRabbit等等。通过一个注解就整合了一个框架，模块化编程的优势就体现在此，今天我们就讲讲在自己的项目框架中如何应用模块化编程的思想来优化框架的设计。

模块化编程，就是把同一模块内的类统一起来，留一个入口作为和外界的交互，模块内部高内聚，模块间低耦合甚至无耦合。项目框架要引入模块时，直接引入其入口类就可；不需要时删除引入，非常方便。每个模块仅包含自身相关的类，这样找相关模块的配置信息时，能快速的通过入口类来定位。

说的不是很直观，先来看我自己框架的结构设计图：  
![Spring模块化设计图][Spring]

看这张图就很直观了，总结就是一点：**用不同的形式不同的类去定义Bean，让每个模块的Bean有一个统一的入口**。

设计建议：

1.  项目应该有一个根配置类(WebContextConfig)，由这个根配置类来引入每个模块，这样也能从这个类上看到当前项目引入了哪些模块
2.  模块化设计应该遵循扁平化原则，垂直层次最好不要超过3层，就是说配置类引入形式不要超过3层，比如 WebContextConfig >> MybatisContextConfig >> 配置类A >> 配置类B ……，层次过深并不好，到时候可能找个配置类都要找半天，自己都不知道哪些类是否定义了Bean，Spring结构变得复杂。
3.  @ComponentScan注解只扫描Service，Controller层，也就是直接的业务层。使用这种形式定义Bean很方便，适合批量的定义，但是有一个弊端，那就是Bean定义得很分散。如果扫描的包大了，想知道某个类有没有定义成Bean，就需要找到那个类，看看是否有相应的注解，如果我要看好几个类，那么就要找好几次。如果某几个类不想定义成Bean了，又得一个一个找，一个一个改，不方便，也容易出错。
4.  每一个模块相关的配置，不论是Bean，还是Profile，还是Annotation等都应该聚合在模块配置类上，而不应该分散定义。
5.  一个模块内Bean的定义形式尽量相同，找起来简单，看起来直观。
6.  自定义框架拓展模块可使用注解封装@Import。比如你定义了一个数据校验模块，和项目没有关联，可在多个项目复用，此时可以用一个注解@EnableDataValidate来间接引入模块的Bean，对项目来说屏蔽非直接相关的配置信息。
7.  项目相关的配置类的引入不要过多封装，让配置类浮现在框架配置的最顶层，便于管理。简单的说就是不要用自定义注解在去封装那些项目配置相关的@Import

[Spring]: /images/20220529/7b9e1159190a41799f72a15aefc70aca.png