为什么要在包上使用许多子项目和依赖项？

Question

I've mostly in my career worked in small or mid-sized java projects. I recently saw a huge project comprising of 30 projects in eclipse. I don't really get concept of creating many small projects and then maintain inter-project dependencies. When do we prefer this over simply organizing stuff in packages?

I guessed it's a maven thing (have mostly been using Ant). I've been reading up on Maven's concept of modules as well – I saw some links on net recommending creation of different modules for web, dao and service layers under a parent module. Is it really a common/best practice?

With or without maven – does such division really makes life easier? Isn't it more compact to have everything in a single project with well-defined packages structure for different layers?

Answer 1

It's common to split up projects into API, implementation, web, etc. components–when there's a need to do so. Large projects are just that: large.

There are benefits to keeping components separate"

• Re-use functionality (eg, the web layer uses the service layer
• Package individual components (eg, ship jus the API to a client)
• Version sub-components; define their version dependencies

You can do all the same stuff with one giant project, but it's more difficult to determine what goes where, and why. Life is easier when those lines of demarcation are clearly defined.

How much easier depends on the project, but when you're dealing with hundreds of thousands of lines of code, occasionally millions, breaking that stuff up saves huge headaches.

Answer 2

Why choose to create a separate module in maven? To help you with your development. There really is no other reason.

The are a number of different reasons why you may want to create a separate module:

1. Separation of concerns: yes, you can do this with packages, but if it's in a separate module, then it can be compiled separately, and you can reduce the amount of tangle[*] in your packages.
2. The modules are managed by different teams, with release cycles of their own.
3. More understandable code: If all of your dao code is in one module, and all of your web in another, you can test them separately.
4. A module can be a separate deployable entity. I have a project which has two web apps, 5 batches and two other core modules (one core for the webapp and one core for the batches). I can now build and deploy each module separately.
5. The modules are published and used externally. If this is true, then you want the minimum amount of 'other' code in this module.

You choose to break up into modules for the same reasons as you would for separating into packages, but at a higher level, at a group of packages.

30 does seem excessive. But there may be good reasons for it. It's up to you and your project to decide what is the right level for the number of modules.

Personally, I try not to split excessively, unless there is a very good reason to do so.

[*] Tangle: mess which describes the links between packages. Package A uses B, which uses C, which uses both A and B. Something which doesn't help understanding.

Answer 3

I think excessive modularisation is akin to over engineering. The best route in my opinion is to start with one module/project and keep with that until such point as it becomes obvious to everyone involved that part of this existing module would benefit from being extracted into its own module. Yes, that means extra work at that point, but for me I'd rather do the work then than endlessly battle with unneeded complexity, in terms of my builds and my development environment, for benefits which are never actually realised.

Unfortunately there seems to be a tendency at the start of a projects to modularise to the nth degree before even a single line of code is written.

Answer 4

这还有另外一个优点..如果我必须在“选定”组件上部署，我不会浪费时间和资源来部署我不需要的依赖项。