kindergarten_java/docs/design/class-management-analysis.md

260 lines
10 KiB
Markdown
Raw Normal View History

2026-02-28 16:41:39 +08:00
# 班级管理功能分析报告
> 分析日期: 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 中期方案(增加配班支持)
引入中间表,支持多教师协作:
```sql
-- 新增:班级教师关联表
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*