3. [Reserved] reading this, others open source project structure should be able to read the

Author: CodeSheep
link: https: //www.jianshu.com/p/fd99bebeadea
Source: Jane books
are copyrighted by the author. Commercial reprint please contact the author authorized, non-commercial reprint please indicate the source.

This article is very well written, reference may be made when designing future project directory structure, it is reproduced over, easy to find.

Why do I write this

Recently, many novice and junior partner or Spring Spring Boot private letters exchanged questions about the project directory structure and code division layered.

Partners represents many small online download open source projects can not read, project structure and layer your code look very Meng, do not know to what kind of ideas to learn and absorb other people's projects.

Well, stay up late liver this article today, and everyone will work together to explore the exchanges, the inadequacies of small partners please criticism.

Ali is the first look at how the agreed

I have the impression, when looking at before, "Ali Baba Java Development Manual", seems to have details about the structure and application engineering hierarchically related, so I turned back to look, and sure enough there:

image

It is this which is probably about the content: on a normal business project in one kind of common project structure and code division level guidance.

Press said in the book are generally divided into the following layers:

Open Interface Layer
Terminal display layer
Web layer
Service Layer
Layer Manager
DAO layer
The external interface or third-party platform

Lack of space in the book, put it this place is more general, with an estimated beginners looked still ignorant, so the next actual project code structure to chatter a chatter specific projects layered structure and code.

The usual project structure

First of all that is in front : This thing does not have a common standard, different companies or teams habits and norms are not the same.

We have to present a very hot Spring typical project structure Boot, for example, created out of the overall project should be divided into three layers:

image

项目根目录/src/main/java: Place project Java source code
项目根目录/src/main/resources: Place project static resource and configuration files
项目根目录/src/test/java: Place the code test project

Located /src/main/javaorganizational structure of the Java source code directory we are more concerned, this place is usually only given a typical structure, after all, different projects and teams do not practice the same, slightly different, but overall arrangements should be about. And if the module multiple projects, then, should correspond to the following structures wherein only one module, other modules code organization is also substantially similar.

image

Details of each directory:

|_annotation：放置项目自定义注解
|_aspect：放置切面代码
|_config：放置配置类
|_constant：放置常量、枚举等定义
   |__consist：存放常量定义 |__enums：存放枚举定义 |_controller：放置控制器代码 |_filter：放置一些过滤、拦截相关的代码 |_mapper：放置数据访问层代码接口 |_model：放置数据模型代码 |__entity：放置数据库实体对象定义 |__dto：存放数据传输对象定义 |__vo：存放显示层对象定义 |_service：放置具体的业务逻辑代码（接口和实现分离） |__intf：存放业务逻辑接口定义 |__impl：存放业务逻辑实际实现 |_utils：放置工具类和辅助代码

Then the next /src/main/resourcesdirectory, which is the main storage of static page static resource configuration files and other things:

|_mapper：存放mybatis的XML映射文件（如果是mybatis项目）
|_static：存放网页静态资源，比如下面的js/css/img
   |__js： |__css： |__img： |__font： |__等等 |_template：存放网页模板，比如thymeleaf/freemarker模板等 |__header |__sidebar |__bottom |__XXX.html等等 |_application.yml 基本配置文件 |_application-dev.yml 开发环境配置文件 |_application-test.yml 测试环境配置文件 |_application-prod.yml 生产环境配置文件

Of course, this place is estimated to have a lot of people will tangle on DTO/VO/DOand other data model definitions to distinguish.

This "Ali Baba Java Development Manual"'d made a strict distinction between so-called, the book is to define the:

DO（Data Object）: One correspondence with the database table structure, upwardly through the transport layer DAO data source object.
DTO（Data Transfer Object）: Object data transfer object, Service Manager, or transmitted outwardly.
BO（Business Object）: Business objects. Encapsulate business logic layer output by the Service object.
AO（Application Object）: Application object. In the abstract object model multiplexing layer between the Web and Service layer, very close to the presentation layer, reusability is not high.
VO（View Object）: Display layer object, typically a Web rendering engine to the transmission layer template object.
Query: Query object data, query request receiving upper layers. Note that more than two parameter query package, prohibit the use of the Map class transmitted.

To be honest, seeing so many definitions of objects, I am also very Mongolia. The actual project development, I think there is no need to deliberately copy objects to define so many layers, so that subsequent objects do the conversion work can bother people skr.

For simplicity, I personally feel, as long as the business logic layer Serviceand the database DAOlayer of an object strict division operating out of each other to ensure that no infiltration, no mix, the problem should not be large.

For example, in Example I above code structure of the project, the Servicetarget layer are defined in the processing dtobag, and the DAOobjects are placed in the layer processing entitybag a.

Project structure divided summary

If this visit a Web site from a user point of view, corresponding to the above code to analyze the structure of the project, can be layered throughout the code:

image

Transfer logic code corresponding to the directory is:

image

I think, we should see more clearly now.

So, after every time we get a new project at hand when, as long as other people to see the code of the project in accordance with this idea, it should basically be able to get along in processing .

Some notes

1, Contorllerlayer parameter passing is not recommended HashMap, it is recommended to use the data model definition

2, Controllerlayer parameters can be done in check, an exception is thrown and other operations, but it is recommended not to put too much business logic, business logic as far as possible into the Servicelayer of code to do

3, Servicelayers do the actual business logic, can be distinguished according to well defined and functional modules can call each other

4, functional module Servicereferencing between, it is recommended not to penetrate into the DAOlayer (or mapperlayers), based on Servicecall and reuse more reasonable level

5, business logic Serviceand database DAOoperations objects layer do not mix. ControllerData objects do not directly penetrate into the layer, DAOlayer (or mapperlayers); Similarly entity object data tables Entitydo not pass directly to Controllerlevel output or display.