kindergarten_java/docs/design/class-management-analysis.md
2026-02-28 16:41:39 +08:00

10 KiB
Raw Permalink Blame History

班级管理功能分析报告

分析日期: 2026-02-22 分析范围: 学校端 vs 教师端 班级管理功能


一、行业最佳实践(调研总结)

1.1 幼儿园班级管理特点

根据调研,幼儿园班级管理通常采用**"主班+配班+保育员"**的三角协作模式:

角色 职责
主班教师 班级负责人,制定教学计划、统筹班级管理、家园沟通
配班教师 协助主班完成教学,关注个体差异,补充教学
保育员 生活照料、卫生保健、协助教学活动

1.2 教务系统班级管理标准功能

根据行业调研,标准的班级管理功能应包括:

学校管理层(学校端)

  • 班级的创建、编辑、删除
  • 班级信息设置(名称、年级、教室等)
  • 班主任/主班教师分配
  • 班级容量设置
  • 班级学生管理(分配、调班)
  • 班级统计数据查看

教师层(教师端)

  • 查看自己负责的班级
  • 查看班级学生列表
  • 班级教学记录
  • 学生表现记录
  • 家园沟通

二、当前系统实现分析

2.1 数据模型现状

┌─────────────────────────────────────────────────────────────┐
│                      当前数据模型                              │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│   ┌──────────┐         ┌──────────┐                        │
│   │  Class   │ ◄───────│ Teacher  │                        │
│   │          │  1:N?   │          │                        │
│   │teacherId │         │classIds[]│                        │
│   └────┬─────┘         └──────────┘                        │
│        │                                                    │
│        │ 1:N                                                │
│        ▼                                                    │
│   ┌──────────┐                                             │
│   │ Student  │                                             │
│   │ classId  │                                             │
│   └──────────┘                                             │
│                                                             │
│   问题双向关联Class.teacherId + Teacher.classIds       │
│   容易导致数据不一致                                         │
└─────────────────────────────────────────────────────────────┘

2.2 现有关联关系

关系 方式 问题
Class → Teacher Class.teacherId (外键) 只能指向一个教师
Teacher → Classes Teacher.classIds (JSON数组) 可指向多个班级
Student → Class Student.classId (外键) 正常

2.3 当前数据状态

Classes:
- 中一班 (id=1): teacher_id=1 (李老师)
- 大一班 (id=2): teacher_id=NULL (未分配)

Teachers:
- 李老师 (id=1): class_ids=[1,2] (声称负责2个班级)

Students:
- 3名学生属于中一班
- 2名学生属于大一班

问题发现:李老师的 class_ids 包含 [1,2],但大一班的 teacher_id 是 NULL数据不一致。


三、需求对比分析

3.1 学校端 vs 教师端 职责划分

功能 学校端(管理视角) 教师端(执行视角)
班级创建 可创建/编辑/删除班级 无权限
教师分配 分配班主任/配班教师 无权限
学生分配 分配学生到班级 无权限(调班需审批)
查看班级列表 查看全校所有班级 只看自己负责的班级
查看学生列表 查看全校所有学生 只看自己班级的学生
班级统计 全校统计数据 自己班级的统计
教学记录 查看所有记录 创建/查看自己的记录

3.2 教师与班级的关系场景

场景1单一班主任制(当前实现)

班级 ──1:1──► 主班教师
  • 一个班级只有一个班主任
  • 一个教师可以负责多个班级
  • 简单直接,适合小型幼儿园

场景2多教师协作制(行业推荐)

班级 ──1:N──► 教师(主班、配班、保育员)
  • 一个班级有多个教师,角色不同
  • 需要中间表 ClassTeacher 关联
  • 适合规范化管理的幼儿园

四、当前实现的问题

4.1 架构问题

问题 描述 影响
双向冗余关联 Class.teacherId + Teacher.classIds 同时存在 数据不一致风险
缺少角色区分 无法区分主班/配班教师 无法支持协作教学
权限控制不清晰 部分API权限边界模糊 教师可能访问不该访问的数据

4.2 功能缺失

缺失功能 重要性 说明
配班教师管理 当前只支持单一班主任
学生调班 学校端无法给学生调班
班级归档 学期结束后班级处理
历史班级 查看往年班级信息

五、方案建议

5.1 短期方案(最小改动)

保持现有数据结构,修复数据一致性问题:

  1. 统一关联关系:以 Class.teacherId 为主,Teacher.classIds 作为缓存字段
  2. 同步机制:每次更新班级教师时,同步更新 Teacher.classIds
  3. API规范化
    • 学校端:完全控制班级-教师关联
    • 教师端:只读访问自己负责的班级
修改点:
- SchoolService 中更新班级教师时同步 Teacher.classIds
- TeacherCourseService 使用 Class.teacherId 查询(已实现)

5.2 中期方案(增加配班支持)

引入中间表,支持多教师协作:

-- 新增:班级教师关联表
CREATE TABLE class_teachers (
    id INTEGER PRIMARY KEY,
    class_id INTEGER NOT NULL,
    teacher_id INTEGER NOT NULL,
    role TEXT NOT NULL DEFAULT 'MAIN',  -- MAIN主班, ASSIST配班, CARE保育
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
    FOREIGN KEY (class_id) REFERENCES classes(id),
    FOREIGN KEY (teacher_id) REFERENCES teachers(id),
    UNIQUE(class_id, teacher_id)
);

功能扩展

  • 学校端可分配主班/配班教师
  • 教师端可看到同班级的协作教师
  • 授课记录可关联多个教师

5.3 长期方案(完整教务系统)

考虑学期、年级升级等复杂场景:

┌─────────────────────────────────────────────────────────────┐
│                     完整班级管理模型                          │
├─────────────────────────────────────────────────────────────┤
│                                                             │
│  Class (班级)                                               │
│  ├── name: 班级名称                                          │
│  ├── grade: 年级(小班/中班/大班)                            │
│  ├── academicYear: 学年                                      │
│  ├── status: 状态ACTIVE/ARCHIVED                         │
│  │                                                          │
│  ClassTeacher (班级教师关联)                                 │
│  ├── classId                                                 │
│  ├── teacherId                                               │
│  ├── role: MAIN/ASSIST/CARE                                  │
│  └── isPrimary: 是否班主任                                   │
│                                                             │
│  StudentClassHistory (学生班级历史)                          │
│  ├── studentId                                               │
│  ├── classId                                                 │
│  ├── startDate                                               │
│  └── endDate (调班时设置)                                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

六、建议的实施优先级

优先级 任务 工作量 收益
P0 修复数据不一致问题 系统稳定性
P0 统一API权限边界 安全性
P1 学校端学生调班功能 核心功能完整性
P2 配班教师支持 教学协作
P3 学期/历史班级 长期运营需求

七、总结

当前状态评估

维度 评分 说明
数据模型 6/10 基本可用,但有冗余
功能完整性 7/10 核心功能具备,缺少调班
权限控制 7/10 已修复,基本合理
扩展性 5/10 单班主任模式限制扩展

关键决策点

  1. 是否需要配班教师?

    • 如果是 → 采用中期方案,引入中间表
    • 如果否 → 采用短期方案,修复现有问题即可
  2. Teacher.classIds 是否保留?

    • 保留:作为缓存字段,提升查询性能
    • 移除:简化模型,避免数据不一致
    • 建议:保留但改为只读,由系统自动同步

分析完成于 2026-02-22