Write in front
This blog post introduces the directory structure and naming specification based on SpringBoot development. It can solve the problem for you. How to plan the directory structure in the actual project? How to name the directory more standardized? What does each directory mean? Three questions.
Catalog description
servicex // Project name |- admin-ui // Manage SERVICE front-end code (generally put UI and SERVICE into one project for management) |- servicex-auth // Module 1 |- servicex-common // Module 2 |- servicex-gateway // Module 3 |- servicex-system // Module 4 |- src |- main // Business logic |- assembly // Service packaging scheme based on maven assembly plug-in |- bin // Module script (start, stop, restart) |- sbin // Scripts used by the administrator role (environment check, system detection, etc.) |- assembly.xml // configuration file |- java // Source code |- com |- hadoopx |- servicex |- system |- annotation // annotation |- aspect // Aspect oriented programming |- config // Profile POJO |- filter // filter |- constant // Store constant |- utils // tool |- exception // abnormal |- controller // Control layer (match the request through URL, assign it to different receivers / methods for processing, and then return the result) |- service // Service layer interface |- impl // Service layer implementation |- mapper/repository // The data access layer interacts with the database and provides an interface for the service |- entity/domain // Entity object |- dto // Entity objects required by the persistence layer (used for data transmission objects between the service layer and the persistence layer) |- vo // Entity objects required by the view layer (used for data transmission objects between the service layer and the view layer) |- *Application.java // Entry startup class |- resources // resources |- static // Static resources (html, css, js, pictures, etc.) |- templates // View templates (jsp, thymeleaf, etc.) |- mapper // Store the XML configuration corresponding to the data access layer |- *Mapper.xml |- ... |- application.yml // Public configuration |- application-dev.yml // Development environment configuration |- application-prod.yml // Production environment configuration |- banner.txt |- logback.xml // Log configuration |- test // Test source code |- java |- com |- hadoopx |- servicex |- system |- According to the specific situation, store the prepared test cases according to the source directory structure |- target // Compile and package output directory (automatically generated, no need to create) |- pom.xml // POM file for this module |- sql // SQL script required for project |- doc // Simplified development, operation and maintenance manual |- .gitignore // Which files do not need to be transferred to the version control tool |- pom.xml // Project general POM document |- README.md // matters needing attention External Libraries // Related JAR package dependencies
matters needing attention
(1). mapper/repository, the data access layer, interacts with the database and provides an interface for the service (adding, deleting, modifying and querying a table, a '* Mapper.java' and a '* Mapper.xml' correspond to a table (there is an associated query); Mybatis uses mapper and JPA uses repository)
(2). entity/domain, data entity class (Mybatis uses entity, JPA uses domain)
(3). Meanings of POJO, VO, DTO, DO, PO and BO:
- POJO: it is a simple and common JAVA object, which contains business logic processing or persistence logic. But they are not JavaBeans, entitybeans, etc., do not have any special roles, and do not inherit or implement classes or interfaces of any other JAVA framework. Can contain objects similar to JavaBean properties and setter and getter methods that access properties.
- VO(View Object): view object, which is used for display of the display layer and represents the data to be displayed by the display layer. Its function is to encapsulate all the data required by a specified page / component.
- DTO(Data Transfer Object): data transfer object, which is used for data transfer between the service layer and the persistence layer, and represents the data that the service layer needs to receive / return.
- DO(Domain Object): domain object is a tangible or intangible entity object abstracted from the real world.
- PO(Persistent Object): a persistent object, which forms a one-to-one mapping relationship with the data structure of the persistence layer (usually a relational database). Each field (or several fields) in the data table corresponds to one (or several) attributes of the PO.
- BO(Business Object): business object, used to encapsulate business logic into an object, which can include one or more other objects.
- After POJO persistence - > Po; During POJO transmission - > dto; POJO as presentation layer - > Vo