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

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比第一种方法具有明显优势：

所有模块都是独立的。如果明天您将重复使用该模块（例如，您有一个可以与Kafka配合使用的模块）并且拥有微服务，则只需将模块导入maven，所有配置都将自动加载。尤其是如果您使用spring.factories（虽然超出了此问题的范围，但我真的建议您阅读此书以及与该问题相关的良好“补充”知识）
与第一个库相关的另一个可能的优点是，您可以为这些“库”使用单独的源代码控制库（读取Git存储库），而在第一种方法中，您必须始终更新存放所有配置的存储库。
编译。使用第一种方法，您将必须始终编译所有内容（例如，SecurityConfig中的一个bean现在依赖于其他依赖项）-因此，您需要更改该bean安全模块和Java配置（application / common模块）。使用第二种方法，您只需要重新编译安全模块就可以了。同样，根据项目规模，进行更改的人员数量等，这可能非常重要或完全无关紧要。运行测试也是如此，采用第一种方法，您可能必须运行所有项目的所有集成和单元测试，而如果您已经做得足够好以隔离安全模块的开发，则可以运行只有它的测试。

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

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

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

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

1 个答案: