春季-我的配置类应该在多模块项目中的什么位置？

Question

我正在开发一个Spring应用程序，并且在此项目中将功能和层划分为单独的模块。

例如：

??? xx-common
??? xx-service
??? xx-web
??? xx-app

但是，我必须设置很多bean，因此我有许多配置类，其中在这些类中创建的bean将用于模块中分布的组件中。

因此，我有两种不同的样式来管理我的配置类：

第一个，一个模块中的所有配置：

该项目的所有配置类都在一个模块中，因此我们可以在一个包中看到所有配置。

??? xx-common
??? xx-service
??? xx-web
??? xx-app
  ??? com.xxx.config
    ??? ServiceConfig
    ??? DbConfig
    ??? WebConfig
    ??? MQConfig

或者，就像哈利的选择一样，我也可以将所有配置类放入更合适的某个模块中，例如xx-common：

??? xx-common
  ??? com.xxx.config
    ??? ServiceConfig
    ??? DbConfig
    ??? WebConfig
    ??? MQConfig
??? xx-service
??? xx-web
??? xx-app

第二个，每个模块仅包含所需的配置：

每个模块都包含其自己必要的配置类。

??? xx-common
??? xx-service
  ??? com.xxx.config
    ??? ServiceConfig
    ??? DbConfig
    ??? MQConfig
??? xx-web
  ??? com.xxx.config
    ??? ServiceConfig
    ??? WebConfig
??? xx-app

现在，我正在使用选项一，但是我不确定哪种结构布局会更好。任何人都可以给我pros和cons每个风格，并建议正确的样式？

Answer 1

这两个选项一开始都会起作用。这完全取决于您到底将什么分为不同的配置/模块以及原因

我倾向于使用第二种方法，IMO 比第一种方法具有显着优势：

1. 所有模块都是独立的。如果您明天将重用该模块（例如，您有一个可与 Kafka 等配合使用的模块）并且您将拥有微服务，那么您只需在 Maven 中导入该模块，所有配置都会自动加载。特别是如果你使用spring.factories（有点超出了这个问题的范围，但我真的建议你阅读一下这个以及与这个问题相关的一个很好的“补充”知识）

2. 与第一个方法相关的另一个可能的优点是，您可以为这些“库”使用单独的源代码控制存储库（阅读 Git 存储库），而在第一种方法中，您必须始终更新包含所有源代码的存储库。配置。

3. 汇编。使用第一种方法，您必须始终编译所有内容（假设现在的一个 beanSecurityConfig依赖于其他依赖项）——因此您更改了 bean 安全模块和 java 配置（应用程序/公共模块）。使用第二种方法，您只需重新编译安全模块即可。同样，这可能非常重要，也可能完全无关紧要，具体取决于项目规模、进行更改的人数等。运行测试也是如此，使用第一种方法，您可能必须运行所有项目的所有集成和单元测试，而如果您工作得足够好，可以隔离安全模块的开发，那么您将运行只有它的测试。

至于第二种方法的缺点 - 嗯，有些人会更喜欢将配置保留在同一个地方，以便更好地编辑。我个人并不关心，因为所有现代 IDE 都在这里提供了很大的帮助，但也许有些人会不同意。