详情查看：内容管理服务 (opens new window)

1. 介绍

内容管理由教学机构人员和平台的运营人员共同完成。

课程审核状态：未提交、已提交、审核通过、审核未通过 课程发布状态：已发布，未发布，已下线

• 数据建模：本项目的内容管理模块是对平台上的课程进行管理，课程的相关信息比较多，这里在数据库设计了课程基本信息表（课程名称、价格、基本介绍、图片）、课程营销表-》课程计划表-》课程师资表进行存储

• 上传审核：培训机构要发布一门课程需要依次填写课程基本信息、课程营销信息、课程计划信息、课程师资信息，填写完毕后需要提交审核，由运营人员进行课程信息的审核，整个审核过程是程序自动审核加人工确认的方式，通常24小时审核完成。

• 课程发布：课程审核通过即可发布课程，课程的相关信息会聚合到课程发布表中，这里不仅要将课程信息写到课程发布表还要将课程信息（图片、视频）分布式文件系统中，所以这里存在分布式事务的问题，项目使用任务调度的方式去解决这里的分布式事务，保存数据的最终一致性。

课程发布表是为了统计不同机构发布的课程数

2. 业务流程

• 教学机构人员的业务流程如下（对课程进行增删改查）：
  1. 登录教学机构
  2. 维护课程信息（可以删改查上传过的所有课程信息或新增），当添加或修改一门课程时，需要编辑课程的基本信息、上传课程图片、课程营销信息、课程计划、上传课程视频、课程师资信息等内容
  3. 课程信息编辑完成，通过课程预览确认无误后提交课程审核。
  4. 待运营人员课程审核通过后方可进行课程发布
• 运用人员的业务流程如下：
  1. 查询待审核的课程信息
  2. 审核课程信息
  3. 提交审核结果

当机构人员新增或修改课程信息后，会自动跳转到课程计划的查询，然后可以对课程计划进行对应的增删改查操作，对课程计划操作完成后会跳转到师资

这部分要完成的内容包括

• 添加课程、添加课程计划、添加师资信息
• 修改课程、修改课程计划、修改师资信息
• 删除课程、删除课程计划、删除师资信息

3. 请求模型类

本项目中有两种模型类：DTO数据传输对象、PO持久化对象。

• DTO用于接口层向业务层之间传输数据
• PO用于业务层与持久层之间传输数据

有些公司还会设置VO对象，VO对象用在前端和接口层之间传输数据

当前端有多个平台且接口存在差异时，就需要设置VO对象用于前端和接口层传输数据。比如：课程列表查询接口，根据用户需求，用户在手机端也要查询课程信息，此时课程查询接口是否需要编写手机端和PC端两个接口呢？

如果用户要求通过手机和PC的查询条件或查询结果不一样，那此时就需要定义两个Controller课程查询接口，每个接口定义VO对象与前端传输数据

• 手机查询：根据课程状态查询，查询结果只有课程名称和课程状态
• PC查询：可以改根据课程名称、课程状态、课程审核状态等条件查询，查询结果也比手机查询的结果内容多

此时，Service业务层尽量提供一个业务接口，即使两个前端接口需要的数据不一样，Service可以提供一个最群的查询结果，由Controller层进行数据整合。

4. 全局异常处理器

从Spring 3.0 - Spring 3.2版本之间，对Spring架构和SpringMVC的Controller的异常捕获提供了相应的异常处理

• @ExceptionHandler：Spring3.0提供的标识，在方法上或类上的注解，用于表明方法的处理异常类型
• @ControllerAdvice：Spring3.2提供的新注解，用于增强SpringMVC中的Controller。通常与@ExceptionHandler结合使用，来处理SpringMVC的异常信息
• @ResponseStatus：Spring3.0提供的标识在方法或类上的注解，用状态码和应返回的原因标记方法或异常类。调用处理程序方法时，状态码将应用于HTTP响应

通过上面的注解便可实现微服务全局异常处理，具体代码如下

/**
* @description 全局异常处理器
*/
@Slf4j
@ControllerAdvice
public class GlobalExceptionHandler {
    @ResponseBody
    @ExceptionHandler(XueChengPlusException.class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) // 该异常枚举错误码为500，
    public RestErrorResponse customException(XueChengPlusException exception) {
        log.error("系统异常：{}", exception.getErrMessage());
        return new RestErrorResponse(exception.getErrMessage());
    }

    @ResponseBody
    @ExceptionHandler(Exception.class)
    @ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR)
    public RestErrorResponse exception(Exception exception) {
        log.error("系统异常：{}", exception.getMessage());
        return new RestErrorResponse(exception.getMessage());
    }
}

5. JSR303校验

前端请求后端接口传输参数，是在Controller中校验还是Service中校验？ 答案是都需要校验，只是分工不同

• Controller中校验请求参数的合法性，包括：必填项校验、数据格式校验，比如：参数是否符合一定的日期格式等,Controller中可以将校验的代码写成通用代码

• Service中要校验的是业务规则相关的内容，比如：课程已经审核通过，所以提交失败等,Service中需要根据业务规则去校验，所以不方便写成通用代码

早在JavaEE6规范中，就定义了参数校验的规范，它就是JSR-303，它定义了Bean Validation，即对bean属性进行校验

SpringBoot提供了JSR-303的支持，它就是spring-boot-stater-validation，它的底层使用Hibernate Validation，Hibernate Validation是Bean Validation的参考实现 所以我们打算在Controller层使用spring-boot-stater-validation完成对参数的基本合法性进行校验

JSR-303相关注解：@NotEmpty，@Size，@NotNull，如果同一个属性需要用到不同的校验规则，则要使用分组校验

比如：订单标号是由系统生成，所以在添加订单时，要求订单编号为空；但是在更新订单时，要求订单编号不能为空。