学习总结学习理解了Fastapi的基本业务逻辑以及与Springboot的关联性对分层架构Layered Architecture的核心增进了理解。我发现在Fastapi与Springboot中都存在着从Springboot: Controller-Service-Repository(Mapper)Fastapi: Controller-Service-DAO这种类似的架构同时理解辨析了VO与DO的区别DO为数据库的镜像投影在DAO中可以调用DO中的变量来操作数据库vo中的数据则是通过controller-service调用封装传到前端或者获取前端的数据而二者的联系应该是在service层中相互转化vo的数据通过service层的方法传入dao层再赋值给do来操作数据库。如下图业务流程万变不离其宗前辈们的智慧还是太强大了OVO熟悉了FastAPI的业务逻辑后编写与修改就变得简单了许多啊。遇到的问题蛇形命名snake_case与驼峰型命名camelCase注意注意一定要在service构建字典中和vo转到前端里面匹配可恶的AI害我改了又改一开始全是NULLFASTAPI真的是一个考验规范链接的框架。。。。。SpringBoot里有类似于的显式映射而FastAPI里面并没有需要手动处理感谢每一个默默付出的大模型开始以为是DO结果并不是也是成功了随之而来的新问题是虽然获取到数据却有部分没有显示出来只在管理员端对不起管理员端的同学T.T解决方法最后的最后找到了解决问题的方法在 PageModel.model_dump 里对rows的每一项若是dict或带__table__的ORM统一用 CamelCaseUtil.transform_result 转成驼峰dict再处理一层嵌套如dept、items。方法如图具体逻辑不再讲述这个的方法的作用为不管传进来是什么字典、对象、元组我都把它变成驼峰命名的字典这样就相当于统一了命名的规则Springboot的显式映射真是好东西后端架构介绍简单介绍一下我的后端架构前端基本使用ai生成还是有些丑陋T.T首先是典型的分层架构后端采用 Controller → Service → DAO 三层架构Controller--àService--àDAO同时在Dict和ORM对象使用方面的一个基本对比调这两个的驼峰形与下划线蛇形兼容很费劲维度ORM对象Dict字典适用阶段DAO 层、写入操作Service→Controller 返回、动态拼装优势类型安全、IDE 提示、可 flush 获取主键灵活、可合并多表字段、易序列化典型用法select(Model)、db.add(obj)CamelCaseUtil.transform_result()、{c.name: getattr(...)}本项目策略写入 简单查询用 ORM返回前端 动态关联用 Dict这里还会出现一些小问题。由于混合的使用和开发时候的粗心大意导致有些命名格式及其不规范在这里也是改了又改功能演示下面是我的功能演示比起上周的只有一个前端改善很多健康档案首先健康档案处可以实现基本信息填写个人画像目前我已经基本实现了患者端的挂号功能用图片来做基本演示选择医生预约详情挂号界面如上图我的预约我的预约初可以查看全部预约此时医生可以看到处方开具患者端查看以及查看处方详情项目逻辑简单讲解一下我目前所做的项目逻辑DODO基本上是对数据库的一个映射类似Springboot里的实体类想查什么写什么下图预约的DO不过多赘述voVO我的理解里VO要拿到前端传回的内容虽然在Springboot里基本上用map拿回来了不咋写VO所以VO的设计很多基本上前端的一个表格对应着后面的一个VO基础的响应模型VO视图就不展示了这里以医生列表为例下面图是 前端显示一一对应即可业务流程以及分层体现医生列表展示 (Query Phase)此阶段主要解决数据获取与展示的问题。数据查询前端发起挂号页面请求后端在 DAO 层通过 med_clinic_doctor 表查询所有状态正常的医生。关联映射为了满足前端展示需求需通过 JOIN 关联 sys_user 表以获取医生账号状态并关联 sys_dept 表以获取科室名称。数据封装Service 层将查询到的 DO 列表转换为前端所需的 VO 格式通过分页工具PageModel包装后返回。此过程需注意字段命名规范Snake Case 转 Camel Case确保前端能正确解析数据。涉及转换方法我已经在前文提到号源查询与状态生成 (Selection Phase)此阶段涉及内存计算与数据库查询的结合逻辑相对复杂。参数接收前端传入 doctorId 和 queryDate。数据库比对后端查询 med_clinic_appointment 表获取该医生当日所有已被预约状态为 0 或 1的记录。状态生成在内存中预设 08:00-17:00 的所有时段共 18 个 Slot。通过比对数据库中的已占时段将剩余时段标记为 available: true已占时段标记为 available: false。这种“全量生成状态覆盖”的逻辑有效避免了频繁的数据库轮询提升了接口响应速度。自动建档与冲突检测 (Validation Phase)在事务提交前必须进行严格的业务规则校验。自动建档Auto-Registration在 Service 层校验用户状态。若发现该用户在 med_patient 表中无档案记录则自动执行创建逻辑。以当前登录用户信息生成 patient_name 并插入新记录。这一机制实现了业务逻辑的无感化极大优化了首诊患者的使用体验。时段冲突检测Conflict Detection在写入前再次校验 med_clinic_appointment 表。若发现目标 slot_start 时段已存在状态为“已预约”或“已完成”的记录则立即抛出业务异常“该时段已被预约”。这是防止号源超卖的关键锁机制。如图所示约满不可再约后面是预约写入与事务管理 (Persistence Phase)这个算是前人的智慧框架真的很完善和规范可惜遇到了不太规范的开发者此阶段严格遵循 ORM 规范与事务一致性。对象构建利用 SQLAlchemy ORM 构建 MedClinicAppointment 对象并通过 db.add() 加入会话。主键获取调用 db.flush() 方法。这一步至关重要它将 SQL 发送到数据库执行但未提交从而获取数据库自增的 appointment_id供后续业务如日志记录或关联操作使用。事务提交待所有业务逻辑校验无误后由 Service 层统一执行 db.commit()正式提交事务确保数据的原子性。结语能看到这里的说明还是有人愿意看我的博客总结一下吧以上是工作成果和产出这周的产出没有想象中的那么多本周工作基本是这些了解Fastapi的框架和我想象到的Sringboot还是有很大的区别的显式映射我真得狠狠夸完善了一下挂号功能AI是很好用但是细节的处理还是要我们来检查或许是我给他说的不对总之是耗费了许多世界。如果是Springboot的话或许直接疯狂产出了。目前在与医生端同学沟通写住院的事宜等我查一眼项目书没有就偷偷不做而且网页版的话搞这个好像是有些多余下周计划下周准备研究一下1.在线支付这些内容内网穿透啥的研究研究加上购买系统2.大模型的同学应该搞差不多了把他的大模型部署下来看看如何完成对话。3.再次完善一下我的交互逻辑下个星期首当其冲要完成命名规范的统一这种隐藏的东西还是很重要的不能再每次出错每次改。。。。这周差不多就是这些了给下周工作的cpy加油吧