前言
在做了这么多架构铺垫之后,一位订阅同学非常期待我能更新主线API,我觉得他的想法非常合理,所以今天就来安排~~~
我主要考虑的是:首先输出主线API,是能让你先鸟瞰全貌,更容易发现设计上存在的问题,然后我再从架构设计上解决这些问题,那么你就能更清楚架构上为什么这么设计!自然水到渠成!
先抛出问题,本文主要引出的痛点是:
1. 校验逻辑不通过时,如何更优雅的处理?
2. 校验是否是管理员,如何通用的实现?
OK,我在【4.2 图书借阅系统数据库设计】中有对需求和数据库设计的详细说明,本文不再赘述!对于图书管理模块,我主要拆分为以下4个API:
- 图书录入和修改API
本文实现
包含字段:图书编号、图书名称、图书类型、作者、图书简介、图书封面、出版社、出版时间
注意: 需要验证图书编号不能重复
说明:之所以录入和修改合并为一个API,是因为修改与录入字段一致!仅通过id是否为空区分是录入还是修改。 - 图片上传API
7.2实现 - 图书列表API
7.3实现 - 图书详情API
7.4实现
以上API均是由管理员admin在后台系统操作,所以都需要验证是否为管理员身份!
对于图片录入和修改API,其实我们在【2-2. SpringBoot API开发详解 】曾定义过,不过定义的比较简单,没有考虑需求细节,所以接下来让我们来完善它!

一、service层
需要增加验证图书编号不能重复的逻辑!
BookServiceImpl.saveBook()
这里使用在 5.6 Mybatis代码生成器Mybatis Generator (MBG)实战详解 学习过的mbg example为例,实现使用Mybatis从Mysql查询图书编号是否存在的代码:
private boolean exists(String bookNo, Integer excludeId) {
本文探讨在开发图书录入和修改API时如何优雅地处理校验逻辑,包括图书编号的唯一性检查以及管理员身份验证。通过示例展示了在service层使用Mybatis进行查询,并提出返回值设计的考量,强调了通用性和可扩展性的需求。同时,提到了在web层和BO、VO对象的调整,以及未来将通过拦截器实现全局的角色权限校验。
订阅专栏 解锁全文
2796

被折叠的 条评论
为什么被折叠?



