【问题标题】：Spring - Where should my config classes be in a multiple-module project?Spring - 我的配置类应该在多模块项目中的什么位置？
【发布时间】：2019-09-11 07:28:39
【问题描述】：

我正在开发一个 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

或者，像 Harry 的选项一样，我也可以将所有配置类放入更合适的模块中，例如 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并推荐正确的风格？

【问题讨论】：

如果您使用第一个选项，当SecurityConfig 发生时会发生什么？当一项服务想要在同一个数据库引擎中但在不同的服务器/配置中使用不同的数据库时呢？在第一个选项中，每个模块都会将大量不必要的配置加载到应用程序上下文中，并且可能会发生冲突。
我认为您应该将所有config、repository 和utils 类放在xx-common 中

标签： java spring spring-boot directory-structure

【解决方案1】：

这两个选项都可以开始使用。这完全取决于您将哪些内容划分为不同的配置/模块以及原因

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

所有模块都是独立的。如果您明天将重用该模块（例如，您有一个可以与 Kafka 或其他东西一起使用的模块）并且您将拥有微服务，那么您只需在 maven 中导入该模块，所有配置都会自动加载。特别是如果你使用spring.factories（有点超出了这个问题的范围，但我真的建议你阅读这个以及它与这个问题相关的一个很好的“补充”知识）
与第一个相关的另一个可能的优势是，您可以为这些“库”使用单独的源代码控制存储库（阅读 Git 存储库），而在第一种方法中，您必须始终更新包含所有配置的存储库。
编译。使用第一种方法，您必须始终编译所有内容（例如，SecurityConfig 中的一个 bean 现在依赖于其他依赖项）-因此您更改了该 bean 安全模块和 java 配置（应用程序/公共模块）。使用第二种方法，您只需重新编译安全模块即可。同样，这可能非常重要或完全无关紧要，具体取决于项目规模、进行更改的人数等。运行测试也是如此，使用第一种方法，您可能必须为所有项目运行所有集成和单元测试，而如果您工作得足够好以隔离安全模块的开发，您将运行只有它的测试。

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

【讨论】：