软件生命周期
- 需求分析阶段:确定软件的需求、目标和功能,并考虑软件的成本、可行性和限制因素。
- 设计阶段:根据需求分析的结果,进行软件功能及架构的设计,制定软件的详细计划和进度安排。
- 编码阶段:将软件设计方案转化为程序代码,进行开发、调试和测试。
- 测试阶段:对软件编写的程序进行严格测试,检验软件是否符合用户需求并具有足够的稳定性和可靠性。
- 发布和部署阶段:将测试通过的软件发布和部署到用户系统中,并进行用户培训和技术支持。
- 运维与维护阶段:监控和维护软件系统正常运行,及时修复出现的问题和漏洞,满足用户需求并不断更新版本。
- 淘汰和停用阶段:如果软件已经过期或者不再符合用户需求,就需要进行淘汰和停用。
使用@Sql注解
是MyBatisPlus框架提供的注解,用于自定义SQL查询语句。使用@sql
注解,可以直接在Mapper接口中定义SQL查询语句,避免编写大量的XML配置文件。一般来说,@sql
注解比较适合一些简单的查询语句,不适合复杂、动态的查询。如果需要进行复杂的查询,建议使用MyBatisPlus提供的QueryWrapper
或LambdaQueryWrapper
进行构建查询条件
还可以在测试类.上使用@Sql注解,可以作用于此测试类中所有测试方法,但不一定合适。如果只是需要执行测试后,数据库中的数据不会发生变化,还可以在测试方法上,添加@Transactional
注解,可以使得测试后自动回滚,表现为:测试方法对数据的修改不会被保存到数据库中,而真正想要提交的数据再添加@Commit
关于DAO架构
技术是会变化的,当下使用MyBaits / MyBaits Plus是 非常好的选择,以后可能就不是了,如果改为使用其它框架,原本Service调用MyBatis / MyBaits Plus的代码就需要跟随调整。为了更好的实现解耦,DAO层不应该对外直接暴露所使用的技术框架,则可以在Service和MyBatis / MyBaits Plus接口之间加一层
关于Service
- Service是项目中用于处理业务的组件,主要职责是:组织业务流程与业务逻辑,以保障数据的完整性、有效性、安全性
- 安全性:数据会随着我们设定的规则而产生,或发生变化
- 在项目中,专门划分出Service层的主要原因有:
- 分工明确,因为Controller或DAO层均有明确的需要解决的问题,它们不应该关心业务流程与业务逻辑
- Service中的代码应该与框架无关(除了最基础的框架以外,例如Spring),无论你的项目使用什么技术框架,数据处理规则应该是不变的,而Controller和DAO层都是基于某些框架的
- 关于Service中的业务方法的声明原则:
- 返回值类型:仅以操作成功为前提来设计返回值类型,如果视为操作失败,将通过抛出异常表示
- 方法名称:自定义
- 参数列表:通常按照客户端或控制器(Controller) 会传递过来的参数来设计
关于异常
- 在Service中使用抛出异常的方式来表示某种“失败”,在调用Service中的方法时,也会捕获对应的异常,来发现并处理这些“失败”
- 如果抛出的异常是某种已经存在的异常类型,例如使用RuntimeException,在实际执行时,如果因为其它原因导致了RuntimeException,对于方法的调用者而言,将无法正确的区分,最终,捕获并处理时可能不准确
- 为了解决此问题,在Service中抛出的异常必须是自定义异常
- 自定义的异常需要继承自RuntimeException,主要原因有:
- Spring MVC框架有统一处理异常的机制,所以,Service方法始终抛出异常(throw / throws) ,并不处理(不使用try…catch) ,Controller方法也始终抛出异常,则没有必要反复通过throws关键字声明抛出异常!如果继承的父级异常不是RuntimeException,必须在各Service方法、Controller方法都声明抛出异常
Spring JDBC处理事务时,只会根据RuntimeException执行回滚
- Spring MVC框架有统一处理异常的机制,所以,Service方法始终抛出异常(throw / throws) ,并不处理(不使用try…catch) ,Controller方法也始终抛出异常,则没有必要反复通过throws关键字声明抛出异常!如果继承的父级异常不是RuntimeException,必须在各Service方法、Controller方法都声明抛出异常
- 自定义的异常,应该包含带String message参数的构造方法,使得抛出异常时可以封装异常信息
关于异常的描述文本,应该是“谁抛出,谁描述”的原则 - 【强制】不允许任何魔法值(即未经定义的常量)直接出现在代码中
关于Controller
- 开发Controller层时,至少需要:-
- 接收请求,并调用Service处理请求
- 使用全局异常处理器
- 统一处理异常-使用Knife4j框架,生成在线API文档
- 配置Knife4j的API文档显示的文本
- 使用Spring Validation检验请求参数
关于RequestMapping
-
RequestMapping 是 Spring 框架中的一个注解,它用于将 HTTP 请求与指定的处理方法(Controller 方法)进行映射。RequestMapping 可以用来处理 GET/POST 以及其他类型的请求,并将请求参数和路径变量映射到方法参数上。RequestMapping 的使用非常灵活,可以根据不同的参数进行不同的应答。
-
RequestMapping 可以在类级别和方法级别上进行定义。在类级别上定义 RequestMapping 时,它的值会作为 URL 的前缀,而在方法级别上定义 RequestMapping 时,它的值则表示具体的 URL 地址。以下是一些常用的 RequestMapping 注解:
- @RequestMapping:最基本的注解,指定 URL 映射路径。
- @GetMapping:表示处理 HTTP GET 请求。
- @PostMapping:表示处理 HTTP POST 请求。
- @PutMapping:表示处理 HTTP PUT 请求。
- @DeleteMapping:表示处理 HTTP DELETE 请求。
- @PatchMapping:表示处理 HTTP PATCH 请求。
-
需要注意的是,如果一个类和其中的方法都有 RequestMapping 注解,那么方法级别的注解会覆盖类级别的注解,即方法级别的注解会成为具体的 URL 地址。
-
RequestMapping 注解可以帮助我们更加清晰地定义和处理 HTTP 请求,并将请求参数和路径变量映射到方法参数上,让代码更加简洁、易读、易于维护。
MockMvc单元测试
-
测试时使用@AutoConfigureMockMvc注解,它可以自动配置 MockMvc 实例
-
具体使用方法:
-
使用
@AutoConfigureMockMvc
注解需要先添加依赖:spring-boot-starter-test
。 -
@SpringBootTest @Slf4j @AutoConfigureMockMvc public class TagControllerTests { @Autowired MockMvc mockMvc; @Test @Sql(scripts = "classpath:/sql/truncate_table.sql") @Sql(scripts = "classpath:/sql/truncate_table.sql", executionPhase = Sql.ExecutionPhase.AFTER_TEST_METHOD) void addNew() throws Throwable{ log.debug("准备向下代码执行"); String url = "/content/tags/add-new"; String name="茶叶标签 "; String enable = "1"; String sort = "88"; mockMvc.perform(MockMvcRequestBuilders.post(url) .param("name", name) .param("sort", sort) .param("enable", enable) .accept(MediaType.APPLICATION_JSON))//前端接收返回的响应 .andDo(MockMvcResultHandlers.print()); // 追加打印返回的内容 } }
-
在上述测试中,我们使用 @AutoConfigureMockMvc 注解自动配置了 MockMvc,然后使用 @Autowired 注解注入了
MockMvc
实例。在 testGet() 方法中,我们使用mockMvc.perform()
方法来模拟一个请求,并使用accept()
方法是用来以JSON的方式返回给前端。 -
使用
@AutoConfigureMockMvc
可以在不启动完整的应用程序的情况下测试 Spring MVC 控制器类的端点,它可以帮助我们更加方便地进行 Spring MVC 的单元测试。Knife4j使用
-
Knife4j是基于springboot构建的一个文档生成工具,它可以让开发者为我们的应用生成API文档,目的是可以更加方便的基于API文档进行测试,生成的文档还可以导出,然后给到前端开发团队,前端开发团队可以基于API接口写具体的调用。
-
具体使用方法请跳转到:Knife4j
全局异常处理
- 全局的异常处理级别:所有的Spring MVC中的拦截机器(HandlerInterceptor),处理器(@Controller)中的异常。
- 当然,Spring MVC中有内置的异常处理对象,但是呈现的结果对于用户端不友好,所以实际项目我们一般会自定义异常处理
- 具体使用方法请跳转到:全局异常处理