java项目分层设计

java项目分层设计

• 本文根据阿里提出的分层规范撰写，参考文章1、文章2
• 本文旨在简单明了就了解java项目和常见框架的分层模式和目录结构

一、常见Web项目目录

 |- web-project   // 项目根目录
        |- src
            |- main                  // 业务逻辑
                |- assembly          // 基于maven assembly插件的服务化打包方案
                    |- bin           // 模块脚本(启动、停止、重启)
                    |- sbin          // 管理员角色使用的脚本(环境检查、系统检测等等)
                    |- assembly.xml  // 配置文件
                |- java              // 源代码
                    |- com            
                        |- dpz       // 包名
                            |- www     // 项目名
                                |- system
                                    |- annotation     // 注解
                                    |- aspect         // 面向切面编程
                                    |- config         // 配置文件POJO
                                    |- filter         // 过滤器
                                    |- constant       // 存放常量
                                    |- utils          // 工具
                                    |- exception      // 异常
                                    |- controller     // 控制层(将请求通过URL匹配，分配到不同的接收器/方法进行处理，然后返回结果)
                                    |- service        // 服务层接口
                                        |- impl       // 服务层实现
                                    |- mapper/repository // 数据访问层，与数据库交互为service提供接口
                                    |- entity/domain     // 实体对象
                                        |- dto // 持久层需要的实体对象(用于服务层与持久层之间的数据传输对象)
                                        |- vo // 视图层需要的实体对象(用于服务层与视图层之间的数据传输对象)
                                    |- *Application.java  // 入口启动类
                |- resources         // 资源
                    |- static        // 静态资源(html、css、js、图片等)
                    |- templates     // 视图模板(jsp、thymeleaf等)
                    |- mapper        // 存放数据访问层对应的XML配置
                        |- *Mapper.xml
                        |- ...
                    |- application.yml        // 公共配置
                    |- application-dev.yml    // 开发环境配置
                    |- application-prod.yml   // 生产环境配置
                    |- banner.txt    
                    |- logback.xml            // 日志配置
            |- test                  // 测试源码
               |- java               
                    |- com
                        |- dpz
                            |- www
                                |- system
                                    |- 根据具体情况按源码目录结构存放编写的测试用例
        |- target     // 编译打包输出目录(自动生成，不需要创建)
        |- pom.xml    // 该模块的POM文件
    |- sql            // 项目需要的SQL脚本
    |- doc            // 精简版的开发、运维手册
    |- .gitignore     // 哪些文件不用传到版本管控工具中
    |- pom.xml        // 工程总POM文件
    |- README.md      // 注意事项
External Libraries    // 相关JAR包依赖

二、阿里规范

1、分层概述

• 按照阿里的规约，对应的项目会按照如下规范进行分层：

  • 表现层（Controller Layer）：处理用户请求和响应。直接与用户交互。处理用户输入，调用业务逻辑层处理业务。

  • 业务逻辑层（Service Layer）：封装业务逻辑。处理具体的业务逻辑，调用数据访问层以存取数据。

  • 数据访问层（DAO Layer）：与数据库交互，执行CRUD操作。与数据库进行交互。进行SQL操作，数据持久化。

  • 数据模型层（Model Layer）：定义数据结构和对象。定义实体类、DTO等数据结构。

  • 配置层（Configuration Layer）：管理系统配置和初始化。集中管理系统配置，如数据库连接、Bean定义等。

2、具体规范

①表现层（Controller Layer）

• 职责：接收用户请求，调用业务逻辑层处理，返回结果给用户。
• 规范
  • 使用@Controller或@RestController注解。
  • 处理请求时，尽量避免业务逻辑处理，业务逻辑应放在服务层。
  • 请求参数应进行校验，使用@Valid和@Validated注解。
  • 使用@ResponseBody注解处理JSON数据。

示例：

@RestController
@RequestMapping("/user")
public class UserController {
    @Autowired
    private UserService userService;

    @GetMapping("/{id}")
    public ResponseEntity<User> getUser(@PathVariable Long id) {
        User user = userService.getUserById(id);
        return ResponseEntity.ok(user);
    }
}

②业务逻辑层（Service Layer）

• 职责：实现具体的业务逻辑，调用数据访问层方法。
• 规范
  • 使用@Service注解。
  • 业务逻辑应封装在服务层，避免在控制层中直接处理复杂业务逻辑。
  • 对外暴露的服务方法应有明确的业务逻辑和异常处理。

示例：

@Service
public class UserService {
    @Autowired
    private UserRepository userRepository;

    public User getUserById(Long id) {
        return userRepository.findById(id).orElseThrow(() -> new RuntimeException("User not found"));
    }
}

③ 数据访问层（DAO Layer）

• 职责：与数据库进行交互，执行CRUD操作。
• 规范
  • 使用@Repository注解。
  • 避免在DAO中写复杂的业务逻辑。
  • 数据访问接口应定义清晰的查询方法，避免使用过于复杂的SQL语句。
  • 所有的数据库查询后转换为Java映射的对象都以DO结尾，该层与数据表一一对应。

示例：

@Repository
public interface UserRepository extends JpaRepository<User, Long> {
}

④数据模型层（Model Layer）

• 职责：定义应用程序的数据结构和模型。
• 规范
  • 定义实体类和数据传输对象（DTO）。
  • 使用JPA或MyBatis注解映射数据库表字段。
  • 数据访问层（dao）完成查询之后得到的DO对象，service层或者manager层就需要将其转换为DTO对外传输。

示例：

@Entity
public class User {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;
    private int age;
    private String email;
}

⑤配置层（Configuration Layer）

• 职责：集中管理系统配置。
• 规范
  • 使用@Configuration注解定义配置类。
  • 配置类应集中管理Bean的定义和初始化。

示例：

@Configuration
public class AppConfig {
    @Bean
    public DataSource dataSource() {
        return new HikariDataSource();
    }
}

3、其他建议

• 分层职责明确：每个层次应有明确的职责，避免层次之间的职责混淆。
• 统一异常处理：通过全局异常处理类处理系统中的异常，避免在每个层次中重复处理异常。
• 日志管理：在合适的层次记录日志，特别是在业务逻辑层和数据访问层。
• 测试覆盖：各层次应有单元测试和集成测试，确保系统的稳定性和正确性。

三、MVC设计模式

①概述

• MVC模式是一种用于实现用户界面逻辑的系统局部设计模式。

• 将应用程序分为三部分：模型（Model）、视图（View）和控制器（Controller），以便于独立开发、测试和维护各部分。

• 是Xerox PARC在二十世纪八十年代为编程语言Smalltalk－80发明的一种软件设计模式，改设计模式在Java项目中被大量使用，甚至被很多前端框架吸收应用，如Vue。

②特点

• 模型（model）：负责数据和业务逻辑、规则，在javaEE项目中modle命名为Service
• 视图（view）：负责人机交互， 指用户看到并与之交互的界面，如Vue、Jsp技术
• 控制器（controller）：负责接收用户输入，调用模型和视图以实现用户请求。如：Servlet技术

③典型的MVC项目

• 技术栈

  • JSP：负责人机交互（view）

  • Servlet：负责流程控制（controller）

  • JavaBean：负责业务逻辑（model）

④java实例

// 控制器类
@Controller
public class UserController {
    @Autowired
    private UserService userService;
    // 接受用户请求
    @RequestMapping("/user/{id}")
    public String getUser(@PathVariable Long id, Model model) {
        User user = userService.findById(id); // 调用对应模型实现类
        model.addAttribute("user", user);
        return "userView"; // 返回数据给前端视图
    }
}

四、DAO设计模式

①概述

• DAO模式是一种用于分离应用程序的业务逻辑层和数据访问层的系统局部设计模式。

• 主要目的是将数据库操作（如CRUD操作）封装到一个独立的类中，以便于管理和维护数据访问代码。

②特点

• 封装数据库操作: DAO类封装了对数据库的所有访问，提供一组抽象接口，应用程序的其他部分不直接接触数据库操作。
• 易于维护: 数据库访问逻辑集中在一个地方，当数据库结构或查询逻辑发生变化时，只需要修改DAO类，不影响其他代码。
• 可替换性: 可以轻松地替换DAO实现（如从JDBC换成myabtis），而不影响业务逻辑。

③java实例

public interface UserDAO {
    User findById(Long id);
    void save(User user);
    void update(User user);
    void delete(Long id);
}
// 业务逻辑层实现类
public class UserDAOImpl implements UserDAO {
    // 数据库操作的具体实现
}

④命名规范

• PO

  • Persistant Object（持久化对象）的缩写，用于表示数据库中的一条记录映射成的java对象
  • PO仅仅用于表示数据，没有任何数据操作。通常遵循Java Bean的规范，拥有getter/setter方法。

• DAO

  • Data Access Object的缩写，用于表示一个数据访问对象。
  • 使用DAO访问数据库，包括增改删查等操作，与PO一起使用。
  • DAO一般在持久层，完全封装数据库操作，对外暴露的方法使得上层应用不需要关注数据库相关的任何信息。

• VO

  • 本质上是Controller和View层交互是View Object的缩写
  • 用于一个与前端进行交互的对象
  • 那可以使用PO传递数据吗？
    • 实际上，这里的VO只包含前端需要展示的数据即可，对于前端不需要的数据，比如数据库创建和修改的时间等字段，出于减少传输数据量大小和保护数据库结构不外泄的目的，不应该在VO中体现出来，通常遵守Java Bean规范，拥有getter/setter方法。

• DTO

  • 本质是经过处理的PO对象，可能增加或减少PO的属性是Data Transfer Object的缩写
  • 用于表示一个数据传输对象，DTO通常用于不同服务或服务不同分层之间的数据传输。
  • DTO和VO概念相似，并且通常情况下字段也基本一致。但是DTO和VO又有一些不同，这个不同是设计理念上的。（敲黑板，划重点）DTO代表服务层需要接收的数据和返回的数据，而VO代表展示层需要显示的数据。DTO通常遵循Java Bean的规范，拥有getter/setter方法。

• BO

  • Business Object（业务对象）的缩写，将业务逻辑封装为一个对象，这个对象包括一个或者多个其他的对象。
  • 比如一个简历，有教育经历、工作经历、社会关系等等。 我们可以把教育经历对应一个PO，工作经历对应一个PO，社会关系对应一个PO。建立一个对应简历的BO对象处理简历，每个BO包含这些PO。 这样处理业务逻辑时，我们就可以针对BO去处理。

• POJO

  • Plain Ordinary Java Object（普通java对象）的缩写
  • 表示一个简单的java对象，上面说的PO、VO、DTO、BO都是典型的POJO，而DAO一般不是POJO，只提供一些调用方法。

五、三层架构

1、概述

三层架构是指：视图层view（表现层），服务层service（业务逻辑层），持久层Dao（数据访问层），三层架构的出现是为了降低耦合度，在这里，使用面向抽象编程，也就是**上层对下层的调用，直接通过接口来完成，下层对上层的真正服务提供者，是下层实现的接口实现类。**实现类是可以更换的，这就实现了层间的解耦合。

2、特点

• view层： 用于显示数据和接收用户输入的数据，为用户提供一种交互式操作的界面。主要作用是界面展示，接收请求，分发请求。

• service层：实现业务的主要逻辑，是系统架构中体现核心价值的部分。将一个业务中所有的操作封装成一个方法，同时保证方法中所有的数据库更新操作，即保证同时成功或同时失败。避免部分成功部分失败引起的数据混乱操作。

• Dao层：也称为是持久层，其功能主要是负责数据库的访问（可以访问数据库、二进制文件、文本文件等），是对数据库，而不是对数据的操作。简单的说法就是实现对数据表的Select，Insert，Update，Delete的操作。如果要加入ORM的元素，那么就会包括对象和数据表之间的mapping，以及对象实体的持久化。也就是哪个类对应哪个表，哪个属性对应哪个列。持久层的目的就是，完成对象数据和关系数据的转换。

3、SSM项目

• 即SpringMVC、Spring 与 MyBatis 三个框架

• SpringMVC：作为 View 层的实现者，完成用户的请求接收功能。SpringMVC 的 Controller作为整个应用的控制器，完成用户请求的转发及对用户的响应。

• MyBatis：作为 Dao 层的实现者，完成对数据库的增、删、改、查功能

• Spring：以整个应用大管家的身份出现。整个应用中所有 Bean 的生命周期行为，均由Spring 来管理。即整个应用中所有对象的创建、初始化、销毁，及对象间关联关系的维护，均由 Spring 进行管理。

• 项目结构

  src
  └── main
      ├── java
      │   └── com
      │       └── example
      │           ├── controller
      │           │   └── UserController.java
      │           ├── service
      │           │   └── UserService.java
      │           ├── mapper
      │           │   └── UserMapper.java
      │           ├── domain
      │           │   └── User.java
      │           └── Application.java
      └── resources
          ├── mapper
          │   └── UserMapper.xml
          ├── application.properties
          └── templates
              └── userList.html
  

4、Springboot+MP项目

springBoot + mybatisPlus框架一般分为View层、Controller层、Service层、Mapper层、pojo（entity）层。

• View层：视图层

  • 根据接到的数据展示页面给用户，如Vue、JSP

• Controller层：控制器层

  • 响应用户需求，决定用什么视图，需要准备什么数据来显示。
  • Controller层负责前后端交互，接收前端请求，调用Service层，接收Service层返回的数据，最后返回具体的数据和页面到客户端。

• Service层：业务逻辑层，编写业务代码

  • 接口：用来声明方法，名称xxx业务Servicel
  • 继承实现impl接口方法：接口的实现（将mapper和service进行整合的文件），调用mapper层接口查询数据库数据。
  • ServiceImpl存放业务逻辑处理，有一些关于数据库处理的操作，但是不是直接和数据库打交道，有接口，也有接口的实现方法，

• Mapper层：数据操作层，编写数据库操作代码，直接操作数据库

  • 也可以称为DAO层，是数据库CRUD的接口，只有方法名
  • mybatis具体实现在mapper.xml文件中，对数据库进行数据持久化操作（把数据放到持久化的介质中，同时提供CRUD操作）
  • src/main/resource文件夹中的mapper.xml文件，里面存储的是真正的数据库CRUD语句

• Pojo层：数据实体类

  • 存放实体类，与数据库中的属性基本保持一致,用于封装数据库查询出来的数据
  • 一般包括getter、setter、toString方法（未使用插件lombok的情况下）。有的开发写成pojo，有的写成model，也有domain，也有dto。