260 lines
10 KiB
Markdown
260 lines
10 KiB
Markdown
# 班级管理功能分析报告
|
||
|
||
> 分析日期: 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*
|