Shulou(Shulou.com)06/01 Report--

How to carry out the practice of maven module division, I believe that many inexperienced people are at a loss about this. Therefore, this paper summarizes the causes and solutions of the problem. Through this article, I hope you can solve this problem.

Our usual java project module division might look like this:

Controller is the controller layer; service is the business logic implementation layer; dao interacts with the database; util puts some utility classes; constant puts constant classes.

Such module partitioning is common, but it has many drawbacks:

1. With the iteration of the project version, the requirements continue to increase, and the code structure becomes larger and larger, which increases the cost for later maintenance. For example, if we change a controller class, we have to compile the whole project.

2, for example, the util package of the project encapsulates a lot of general tool classes, which can be used by the current project and other projects. If it is the above partition mode, you have to rely on the project war, which becomes very disgusting, because configuring the dependency on war in maven is not as simple and straightforward as relying on jar.

In fact, this division does not follow a design pattern principle: "high cohesion, low coupling". Although we divide the hierarchy by package name, which is good, it is not enough, because in terms of the build level, everything is coupled together. So we need to use Maven partition module (module)

As shown below:

Artmuseum-parent is the parent of all module, the package type is pom, and there is only one pom.xml file for managing module

Artmuseum-common is managed by artmuseum-parent. The project is used to encapsulate tool classes and constants, and the package type is jar.

Artmuseum-manage is also managed by artmuseum-parent, which is the main module of the project and is used to manage the four module of controller, service, dao and pojo. The package type is pom.

The dependencies between module are as follows:

Artmuseum-manage-controller->

Artmuseum-manage-service->

Artmuseum-manage-dao->

Artmuseum-manage-pojo->

Artmuseum-common

This division solves the above drawbacks:

1. Easy to reuse. If you need to use the tool classes in the common package to other project components, you only need to

After mvn install the module of common, you can rely on the generated jar.

2, conducive to expansion and maintenance, modified the controller layer of the code, only need to mvn install this module.

Based on this, I did an aggregation project today, using the SSM framework and implementing an interface to publish the project (simple storage).

The structure of the project is as follows:

The API tests are as follows:

The success of the storage is as follows:

After reading the above, have you mastered how to carry out the practice of maven module division? If you want to learn more skills or want to know more about it, you are welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.