项目目录实践总结（一）

目录的重要性

1. 事物总是这样，一开始是非常简单的，但是随着项目需求量变大，事物就变得复杂了，甚至是不可控的，这里的复杂也是概念间相互关系复杂。可是概念的精准定义是建立在对客户需求的理解深度上，而且对需求的深度理解是需要天赋或者时间沉淀的，可能是理解力极强又或者需要5天甚至1一个月时间才能够理解到位。如果概念定义精准了，并且清晰易懂，也不会存在复杂一说，事物变得简单了，那么这个世界也许就不会那么多痛苦了。
2. 但是也不要消极，如果代码写起来很复杂，很乱，最大可能是自己对需求理解不到位。这是真的。在项目实践的过程中，也是为了赶时间在加上自己的基本功确实还是需要提高，写出了很多if…else语句，这样的代码是根本无法维护的。最后还是把过程式的代码整理成了面向对象的代码。这里并不是说面向对象的代码块好于过程式的代码。后面之所以能够能够写好，是因为随着时间推移，对项目业务需求理解深了，自然而然写出来的代码就特别简单，清晰易懂。可是，哪个公司又愿意给一个开发者这么多时间呢？一个业务逻辑需要迭代多次，才能把代码写到更好。也许是高级工程师或者专家的话，就不会存在自己目前面对的问题。
   借鉴同事说的话：谁都不是一开始就做到最好的。
3. 事物多了，那么就应该把事物进行归类整理。23种设计模式，最后被归为3大类，构建类（创建对象的最佳实践），结构类（构建对象与对象之间，类与类之间，类与接口之间的组织架构关系的最佳实践），行为类（某个具体类的需要完成它单一职责的最佳实践）。
4. 问题是一步一步出现的，是一个逐渐迭代的过程。非常清楚地记得在项目实践过程，需要给某一类功能添加一个具体的功能，这样的情况一开始，是无法预测的。当自己面对这样的问题，直接把代码重构了，就行了，不需要去责备和抱怨，能够遇见问题真的是缘分。所以在写代码的过程中，不要想太多了，什么多访问一次数据库了，什么多了一次循环，没有必要，先跑起来。解决办法就是：我们根本无需去焦虑未来。淘宝的架构体系，也是从单机一步一步演化到服务化的。
5. 最近一次项目实践中，在dto目录下就出现了失控情况。于是对项目目录的一个标准做法做出总结。如果自己没有出现这样的问题，也许永远也不会引起对项目目录结构的重视程度。

maven约定目录

1. .idea文件
   不用管这个文件。.idea文件存放项目的配置信息（版本控制信息，历史记录）。

2. .iml
   iml是 intellij idea的工程配置文件，存放当前project的一些配置信息。

mvc目录结构

1. com.sanding.directory
   sanding是公司名称
   directroy是项目名称

2. common
   这是一个基础设置目录，存放所有基础设施文件，比如配置文件，枚举文件，异常文件，常量文件，注解文件。存跟业务逻辑隔离开的文件即可。

3. controller
   控制器，现在采用前后端分离，主要响应json数据到前端。但是需要引入service并获取到想要的数据，然后在把所有的需要的数据组装起来，最后响应的前端。

4. dao
   数据访问对象，与数据库交互。

5. model
   模型，存储entity(跟数据库表字段一一对象的实体)，存储响应的dto，根据实际情况，前端需要展示什么就显示什么。

6. schedule
   把应用中所有的定时任务都写在这个目录下，如果定时任务较多的话，根据功能模块隔离开即可。并最好使用quartz开源软件实现。

7. service
   写业务逻辑。写的时候一定要把控制逻辑和业务逻辑隔离开。

8. utils
   存放大量的公共工具，字符串非空判断，对象非空判断，文件的工具，excel工具，日期工具，snowflake工具等等，这些东西无需考虑项目是否能够使用到，把最基本的工具类直接拷贝到一个项目中即可。

common目录结构

1. adapter
   项目中自定义的适配器配置文件。如果很多，需要根据职责或者功能模块在次进行分类管理。

2. annotation
   项目中自定义的注解，注解的使用目的，就是隔离基础设置代码和业务逻辑代码。如果很多，需要根据职责或者功能模块在次进行分类管理。

3. aop
   项目中自定义的aop

4. config
   管理所有的配置文件

5. enum
   项目使用到的所有枚举，如果很多，需要根据职责或者功能模块在次进行分类管理。

6. exception
   自定义一个标准异常架构体系文件，每次新项目，直接拷贝使用就行了。

7. interceptor
   自定义的拦截器配置文件。

config

1. async
   项目中会使用一些多线程知识，可以为多线程创建一次线程池，节约资源。
2. oss
   项目使用的文件对象存储。比如使用云文件服务器存储多媒体文件。
3. properties
   项目中会使用很多配置数据，比如路径，公钥私钥，一些业务项目的配置数据，这样的好处是不用代码中写死，采用perperties可以随意更改。
4. redis
   项目中一定会使用到缓存服务，比如session管理，获取活跃用户，某个业务字段的自增，需求大量请求的数据存储到缓存中。
5. shiro
   每个项目都会有用户模块，直接使用开源组件shiro搭建用户鉴权授权功能逻辑。
6. sms
   短信服务，比如用户注册，修改密码，重要事件通知。

model 目录结构

1. model
   是装整个项目用到的模型数据。
2. common
   常规请求响应dto
3. dto
   主要跟前端交互的，一般都会特别多，一定要根据功能模块分离管理，不然后台就 失控了。
4. entity
   这个目录下的文件一般是使用工具自动生成代码，跟表结构一一对应起来，坚决不修改任何一个字段。不作任何的修改操作。

小结

1. 在项目实践中获得的心得体会，觉得工程目录结构非常重要，不然项目目录结构走着走着就失控了。
2. 根据在项目实践中写出了对事物概念理解的心得体会。这个世界没有简单的事情，即使有，也需要想办法做到它的最佳实践。
3. 虽然没有简单的事情，但是也不要消极，当自己真的对需求有足够深的理解后，写出来的代码就特别简单和清晰易懂。借鉴同事的一句话：没有谁一开始就可以做到最好。
4. 每一个最佳的实践，都是从坑爬出来后，接着反思，总结，整理，归纳出来的。
5. 总结并记录了：大体上一个项目需要使用的到目录结构。这个是自己在实践过程中的体会和借鉴同事们已经搭建的目录结构，和借鉴开源软件的项目目录结构，整理而来。
6. 每个大目录下，都需要根据实际情况比如职责分离管理小目录或者功能模块管理小部件。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！