Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Spring - Where should my config classes be in a multiple-module project?

I am developing a Spring app and I have divided the functions and layers into separate modules in this project.

For example:

└── xx-common
└── xx-service
└── xx-web
└── xx-app

However, there are lots of beans that I have to setup, so I have many config classes where the beans created in these classes will be used in components spreaded in the modules.

So, I have two different kinds of style to manage my config classes:

First one, all-configs in one module:

All the config classes of this project in one module, so we can see all the configs in a single package.

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

Or, like Harry's option, I can also put all the config classes into some module more appropriate, like xx-common:

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

Second one, each module only contains configs it needs:

Each module contains its own necessary config classes.

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

For now I am using option one, but I am not sure which kind of structure layout would be better. Can anyone give me the pros and cons of each style and recommend the correct style?

like image 995
Fred Pym Avatar asked Sep 11 '19 07:09

Fred Pym


People also ask

Can we have multiple configuration classes in Spring?

One configuration class can import any number of other configuration classes, and their bean definitions will be processed as if locally defined.

What is the use of multi-module project in Spring boot?

A Spring Boot project that contains nested maven projects is called the multi-module project. In the multi-module project, the parent project works as a container for base maven configurations. In other words, a multi-module project is built from a parent pom that manages a group of submodules.


1 Answers

Both options will work to start with. It all depends on what exactly you separate into different configurations / modules and why

I tend to use the second approach that IMO has significant advantages over the first option:

  1. All modules are self contained. If you'll tomorrow reuse the module (for example you have a module that works with, Kafka or something) and you'll have microservices, then you just import the module in maven and all configurations get loaded automatically. Especially if you use spring.factories (kind of beyond the scope for this question, but I really suggest you to read about this as well its a good "complementary" knowledge relevant for this question)

  2. Another possible advantage that is connected to the first one, is that you can use a separate source control repository (read Git repo) for these "libraries", while in the first approach you'll have to always update the repository that holds all the configurations.

  3. Compilation. With the first approach you'll have to always compile everything (say one bean from SecurityConfig now depends on additional dependency) - so you change that bean securty module and java configuration (application/common module). With the second approach you only recompile the security module and you're good to go. Again, this can be really important or totally insignificant depending on project size, amount of people making changes and so forth. The same holds for running tests, with the first approach you'll probably have to run all the integration and unit tests for all the project, while if you've worked well enough to isolate the development for the Security module, you'll run only its tests.

As for disadvantages of the second approach - well, some people will prefer to keep the configurations in the same place, to better edit. I personally don't really care because all modern IDEs provide a great help here, but maybe some will disagree.

like image 148
Mark Bramnik Avatar answered Oct 20 '22 10:10

Mark Bramnik