项目结构介绍

通常的项目结构

 

各个目录详细介绍：

 

然后接下来/src/main/resources目录，里面主要存放静态配置文件和页面静态资源等东西：

当然，这地方估计有一个很多人都会纠结的关于DTO/VO/DO等数据模型定义的区分。

这在《阿里巴巴Java开发手册》中倒是做了一个所谓的严格区分，那本书上是这样去定义的：

• DO（Data Object）：与数据库表结构一一对应，通过DAO层向上传输数据源对象。
• DTO（Data Transfer Object）：数据传输对象，Service或Manager向外传输的对象。
• BO（Business Object）：业务对象。由Service层输出的封装业务逻辑的对象。
• AO（Application Object）：应用对象。在Web层与Service层之间抽象的复用对象模型，极为贴近展示层，复用度不高。
• VO（View Object）：显示层对象，通常是Web向模板渲染引擎层传输的对象。
• Query：数据查询对象，各层接收上层的查询请求。注意超过2个参数的查询封装，禁止使用Map类来传输。

老实讲，看到这么多对象的定义，我也是很蒙的。实际项目开发时，我觉得没有必要刻意照搬去定义这么多层对象，这样后续做对象转换工作都能烦skr人。

出于简单起见，我个人觉得，只要保证业务逻辑层Service和数据库DAO层的操作对象严格划分出来，确保互相不渗透，不混用，问题应该就不大。

Service层处理的对象都定义在了dto包里，而DAO层处理的对象都放在了entity包里了。

 

一些注意事项

1、Contorller层参数传递建议不要使用HashMap，建议使用数据模型定义

2、Controller层里可以做参数校验、异常抛出等操作，但建议不要放太多业务逻辑，业务逻辑尽量放到Service层代码中去做

3、Service层做实际业务逻辑，可以按照功能模块做好定义和区分，相互可以调用 

4、功能模块Service之间引用时，建议不要渗透到DAO层（或者mapper层），基于Service层进行调用和复用比较合理

5、业务逻辑层Service和数据库DAO层的操作对象不要混用。Controller层的数据对象不要直接渗透到DAO层（或者mapper层）；同理数据表实体对象Entity也不要直接传到Controller层进行输出或展示。

原文链接:https://www.cnblogs.com/exce-ben/p/12602772.html
如有疑问请与原作者联系

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有