请销假管理系统的分层架构设计与核心模块实现

在企业人力资源数字化进程中,请假审批类系统是典型的工作流应用场景。多数现有轻量系统存在业务逻辑耦合度高、假期额度管理粗放、审批流程扩展性差等问题,难以适配不同组织的差异化审批制度。本文基于 Flask 生态设计了一套分层架构的请销假管理系统,通过模块化设计实现业务逻辑解耦,重点解决假期额度精细化管控、多级平行审批、定时任务自动化三类核心工程问题,为同类 Web 管理系统的开发提供可复用的架构参考。

一、整体架构设计

系统采用经典的三层 B/S 架构,同时引入独立的定时任务调度模块,各层通过明确的接口定义交互,实现职责分离。

1. 架构分层与职责

  • 数据访问层:基于 Flask-SQLAlchemy 构建 ORM 模型层,封装所有数据库操作,向上提供统一的数据读写接口,屏蔽底层 SQL 细节。通过模型类的约束与关联关系保证数据一致性,核心表包括用户表、年度额度表、请假申请表、假期占用表、节假日表等。

  • 业务逻辑层:系统核心层,封装审批服务、额度服务、节假日计算服务、定时任务服务四大业务模块,每个模块内聚单一职责,通过函数调用完成业务流程编排。

  • 表现层:基于 Jinja2 模板引擎与 Bootstrap 构建 Web 界面,负责接收用户请求、调用业务层接口、渲染结果页面,同时处理权限校验与前端交互逻辑。

  • 定时任务模块:基于 APScheduler 的后台独立线程,负责执行每日自动销假、年度额度结转等异步任务,通过数据库状态与业务层同步,不影响主线程请求响应。

2. 核心设计原则

  • 状态与标志分离:审批流程同时使用全局状态字段与各级审批标志位,既便于快速筛选待办,又支持平行审批等复杂流程。

  • 延迟占用机制:假期额度不在申请提交时扣除,而在审批通过且假期生效后占用,避免驳回后额度回滚的复杂度。

  • 冗余字段优化:在申请表中冗余存储审批人姓名等字段,减少列表查询时的跨表联查,提升页面加载速度。

二、各层工程化实现

1. 数据层:模型设计与约束

数据层通过数据库模型定义业务实体与关联关系,利用联合唯一约束、外键约束保证数据完整性。以年度假期额度表为例,通过UniqueConstraint保证每人每年仅有一条额度记录,避免数据冗余与不一致。

python 复制代码
class AnnualLeaveQuota(db.Model):
    """年度假期额度模型"""
    id = db.Column(db.Integer, primary_key=True)
    user_id = db.Column(db.Integer, db.ForeignKey('user.id'), nullable=False)
    year = db.Column(db.Integer, nullable=False)
    annual_leave = db.Column(db.Integer, default=0)
    marriage_leave = db.Column(db.Integer, default=0)
    personal_leave = db.Column(db.Integer, default=0)
    # 其余假期类型字段省略
    
    # 联合唯一约束:每人每年一条记录
    __table_args__ = (
        db.UniqueConstraint('user_id', 'year', name='_user_year_uc'),
    )
    
    user = db.relationship('User', backref='leave_quotas')

2. 业务层:审批状态流转引擎

审批流转是系统的核心业务逻辑,系统设计了状态机式的流转算法,支持最多四级审批与平行审批人配置。核心思路为:每次审批操作更新对应审批人的标志位,随后校验本级是否全部通过,若通过则根据审批层级配置更新全局状态,进入下一级或直接办结。

python 复制代码
def handle_approved_status(req):
    """审批通过后状态流转处理"""
    # 一级审批完成校验
    if req.status == 'pending':
        if req.approver_1_approved and (not req.approver_1_parallel_id or req.approver_1_parallel_approved):
            if req.approver_2_id:
                req.status = 'dept_pending'
            else:
                req.status = 'approved'
                occupy_leave_days(req.user, req, req.days, req.start_date.year)
    # 二级及后续审批校验逻辑同理,逐级判断
    elif req.status == 'dept_pending':
        # 二级审批完成判断逻辑省略
        pass
    
    db.session.commit()

3. 任务层:定时任务与防抖设计

系统利用 APScheduler 执行周期性任务,同时通过请求钩子做双重保障,确保自动销假逻辑每日必执行。为避免高频请求导致重复执行,设计了日期级别的防抖机制,每天仅执行一次自动销假逻辑。

python 复制代码
from apscheduler.schedulers.background import BackgroundScheduler
from datetime import datetime

last_auto_cancel_date = None

@app.before_request
def before_request():
    """请求钩子:每日首次请求触发自动销假"""
    global last_auto_cancel_date
    today = datetime.today().date()
    if request.endpoint != 'static' and last_auto_cancel_date != today:
        auto_cancel_leave()
        last_auto_cancel_date = today

# 初始化定时调度器
def init_scheduler(app):
    scheduler = BackgroundScheduler()
    # 每天凌晨1点执行自动销假
    scheduler.add_job(
        func=auto_cancel_leave,
        trigger='cron',
        hour=1,
        minute=0,
        id='auto_cancel_leave'
    )
    # 每年1月1日凌晨2点执行额度结转
    scheduler.add_job(
        func=reset_annual_leave_days,
        trigger='cron',
        month=1,
        day=1,
        hour=2,
        minute=0,
        id='annual_quota_reset'
    )
    scheduler.start()

三、系统性能优化手段

  1. 索引优化:针对高频查询字段(用户 ID、申请状态、日期范围)建立数据库索引,显著提升列表查询与筛选的响应速度。

  2. 计算下沉与分批处理:统计报表场景下,复杂的剩余额度计算无法通过 SQL 直接完成,采用 "先筛选用户再批量计算" 的策略,配合手动分页,避免全量计算导致的接口超时。

  3. 事务控制:额度占用与返还、审批状态变更等关键操作包裹在数据库事务中,异常时自动回滚,保证数据一致性。

  4. 连接复用:利用 Flask-SQLAlchemy 的请求级连接池,避免频繁创建销毁数据库连接,提升并发场景下的稳定性。

四、系统测试与性能评估

在 Windows Server 环境下对系统进行全面测试,结果如下:

  • 功能测试:覆盖用户认证、请假申请、多级审批、销假返还、额度管理等 10 项核心功能,所有测试用例全部通过,业务流程符合预期。

  • 性能测试:模拟 50 并发用户持续压测 5 分钟,平均响应时间 238ms,95 分位响应时间 412ms,无请求失败,满足中小型企业日常使用需求。

  • 安全性测试:通过参数化查询规避 SQL 注入风险,基于角色的权限控制有效拦截越权访问,密码哈希存储保证用户信息安全。

五、架构优势与局限分析

架构优势 :分层清晰,业务模块解耦,新增假期类型、扩展审批层级仅需修改对应模块,无需重构整体流程;基于 SQLite 的嵌入式设计部署成本极低,适合快速落地。

架构局限:SQLite 的写锁机制限制了超高并发场景的写入性能;模板渲染的前后端耦合模式在复杂交互场景下维护成本较高。

六、总结与架构演进方向

本系统的分层架构设计有效解决了请销假业务的流程管控与额度管理问题,工程化的模块拆分与状态机设计为同类审批系统提供了可复用的实现思路。后续架构演进可从三个方向推进:一是数据层适配 MySQL 并引入连接池,提升并发承载能力;二是前后端分离改造,通过 RESTful API 解耦前后端;三是引入工作流引擎,实现更灵活的流程可视化配置。

完整功能演示可在B站搜索:兵慌码乱 查看。

相关推荐
mqiqe2 天前
LLM Gateway:企业级大模型应用的“统一控制平面”
平面·flask·gateway
aGdF8E3gQ2 天前
【Application Insights】采样率对Function App日志收集的影响和解决方法
python·flask·wpf
编码者卢布2 天前
【Azure APIM】通过 API Management 公开API为 MCP Server 的试验 (二)
microsoft·flask·azure
编码者卢布3 天前
【Azure APIM】通过 API Management 公开现有 MCP Server 的试验 (一)
microsoft·flask·azure
这个人懒得名字都没写4 天前
Flask + PyArmor Gunicorn启动报错:RuntimeError: unauthorised use of script
python·flask·gunicorn·pyarmor
立心者05 天前
Sdcb Chats .. 发布,彻底移除 Azure.AI.OpenAI 专用包
人工智能·flask·azure
昆曲之源_娄江河畔6 天前
Python如何安装flask, pymssql
开发语言·python·flask·pymssql
韭菜炒鸡肝天6 天前
【App Service】在Azure环境中如何查看App Service实例当前的网络连接情况呢?
microsoft·flask·azure
看昭奚恤哭6 天前
ontainer App】Container App无法从Container Registries 拉取镜像 - 报错 Forbidden
后端·python·flask
米码收割机6 天前
【python】Flask 贵州省兴仁市藠头价格数据分析和可视化系统(源码+文档)【独一无二】
python·数据分析·flask