简介这是一套演示MVC三层架构的Java Web应用案例代码面向正在学习Java Web分层设计、需要理解Controller/Servlet与Model/MyBatis配合方式的开发者项目以具体业务功能为主线涵盖从前端表单到数据库访问的完整请求链路适合作为课程设计或毕业设计的前期参考。资源共121个文件压缩包约6.86MB其中32个java源文件对应各层核心逻辑29个xml文件用于MyBatis映射与Maven工程管理9个jsp和3个html页面构成视图层另有properties、css等配置文件与样式表源码和编译后的class文件一并提供便于对照阅读和排错。项目围绕brand-demo模块展开用户通过HTML表单和JavaScript发起交互Servlet作为控制器接收请求并调用业务处理再由MyBatis执行MySQL数据操作最终把结果交给JSP渲染输出完整呈现了从页面到数据库再回到页面的MVC处理闭环。目前已有1703人学习下载可用它搭建本地运行环境、观察各层代码依赖关系快速建立对MVC与Java Web技术栈的整体认识。1. MVC三层架构被误读最多的地方Model不是数据表三层不是三个包很多刚开始写业务系统的同学看到“MVC三层架构”这个提法会以为它就是把代码放进 models、views、controllers 三个文件夹里真动手的时候又容易把所有 SQL 都塞进路由回调里跑通一遍就觉得自己已经会了。这套理解不是 MVC只是目录长得像。MVC 三层架构真正说的是模型 Model 只负责数据和业务规则视图 View 只负责把数据渲染出来控制器 Controller 只负责接请求、调模型、选视图三者之间单向依赖谁也别越界。这篇我用一份能直接跑起来的最小记账 Demo把典型 MVC 案例拆开讲清楚——代码很短但职责边界、参数校验、常见踩坑全在里面。适合刚开始接触后端分层的开发者也适合已经写过几天业务代码、但总觉得 Controller 越写越乱的人。2. 先立住概念三个角色各自管什么请求路径怎么走2.1 一次HTTP请求在MVC里的完整流转路径一个 MVC 请求的标准路径是固定的。用户在前端页面发起操作浏览器把 HTTP 请求发给服务器服务器里的路由表先匹配 URL命中后把请求转给对应的控制器方法。控制器先做参数预检再调用模型的方法模型去数据库读取或写入数据然后把结果原样返回给控制器控制器拿到结果后决定“渲染哪个视图”或者“重定向到哪个 URL”视图只做模板填充把控制器传过来的数据变成 HTML 返回给浏览器。拿我们马上要写的记账 Demo 举例用户提交一笔支出POST 请求到达/add。控制器的add_expense方法接住表单参数调用ExpenseModel.add()让它把记录插入 SQLite 数据库插入成功后控制器返回一个重定向到首页浏览器收到重定向后再次发起 GET/请求控制器调用list_all()和total()拿到记录列表和总金额传给模板模板循环渲染出页面。这个过程中每个角色只有一件事可做。控制器不写 SQL不做 HTML 拼接不算总额模型只操作数据库不关心页面长什么样视图只做展示不在模板里做统计。任何一个请求你都能沿着“路由 → 控制器 → 模型 → 控制器 → 视图”这条链把它讲完这就是 MVC 最容易理解、也最不容易跑偏的检查方式。2.2 MVC与三层架构的本质区别一个管职责一个管整体切分“MVC 三层架构”这个说法经常被混用实际它是两套维度叠在一起。MVC 关注的是一个请求处理过程中代码职责怎么划分三层架构关注的是整个系统按纵向怎么切成表现层、业务层、数据层。MVC 里的 Controller 和 View 都属于表现层Model 则覆盖了业务层和数据层的大部分内容。对比维度MVC三层架构关注点单个请求的职责分配整个系统的纵向层级最小单元模型 / 视图 / 控制器表现层 / 业务层 / 数据层常见落地一个模块内部的代码组织整个工程从上到下的结构我一般写小型业务系统时直接让 Model 承担数据访问和业务规则两件事Controller 承担表现层的调度View 只做渲染。等项目里 Model 超过 200 行、出现多个模块共享同一套业务逻辑时再把 Model 里偏业务规则的部分拆成独立的 Service 层这时候就变成了“三层架构里面的 MVC”。如果你一上来就把 Controller、Service、DAO 全部分好小项目很容易被抽象拖垮这个坑第 5 章会重点讲。2.3 项目到多大规模才值得上MVC有同学问是不是所有项目都该套 MVC我的判断标准是三条。第一条同一份数据要同时供给网页和接口时如果没有 Model 层两个路由各写一份 SQL改一次表结构要改两处地方漏改一处线上就翻车。第二条多个页面共用同一类数据操作把 SQL 抽成 Model 方法后一次修改全局生效。第三条Controller 开始出现超过三五十行的趋势说明视图调度和业务逻辑已经混在一起了不拆迟早要乱。反过来项目只有三个页面、几个接口、全部代码不到 500 行硬套 MVC 反而会增加负担。最典型的现象是改一个字段要打开五个文件先改数据库、再改 Model、再改 Controller、再改模板、再改测试。这种情况下我建议先不建目录保持线性代码等真的出现重复逻辑再抽。MVC 是为了应对“复杂度增长”的不是为了装饰工程结构。3. 最小可运行案例用Flask写一个MVC记账Demo3.1 为什么用Flask而不是Spring Boot来演示MVC选 Flask 不是因为 Python 比 Java 好而是因为 Flask 的 MVC 边界最直白路由函数天然就是 ControllerJinja2 模板就是 View普通 Python 类就是 Model。整个过程没有任何注解、依赖注入、容器管理的干扰你能一眼看清数据在哪进去、从哪出来。Java 背景的读者做一次映射就能对齐这里的ExpenseModel对应你熟悉的 DAOapp.py里的路由方法对应 Servlet 或 SpringMVC 的 Controllerlist.html对应 JSP 或 Thymeleaf 模板。完整项目只需要三个文件加一个数据库文件结构如下demo/ ├── app.py # 入口同时是 Controller 层 ├── models.py # Model 层封装全部数据库操作 ├── views/ │ └── list.html # View 层只做渲染 └── db.sqlite3 # SQLite 数据库首次运行自动生成提示目录名字叫 views 只是工程习惯和三层架构里的“表现层”不是一个概念别混着记。3.2 Model层四个方法封装全部SQL对外只暴露数据操作Model 层的原则是所有 SQL 都收在模型内部外部调用者只知道“我要添加一笔记录”“我要拿全部记录”“我要算总额”不关心数据库是 SQLite 还是 MySQL。这样将来换数据库或者改表结构只改这一个文件就够了。# models.py import sqlite3 class ExpenseModel: Model 层只负责数据读写不包含 HTTP 相关逻辑 def __init__(self, db_pathdb.sqlite3): self.db_path db_path self._init_table() def _init_table(self): # 建表操作幂等重复执行不会报错 with sqlite3.connect(self.db_path) as conn: conn.execute( CREATE TABLE IF NOT EXISTS expense ( id INTEGER PRIMARY KEY AUTOINCREMENT, amount REAL NOT NULL, category TEXT NOT NULL, note TEXT DEFAULT , created_at TEXT DEFAULT CURRENT_TIMESTAMP) ) def add(self, amount, category, note): # 业务规则统一在这里把关谁调用都绕不过 if not amount or amount 0: raise ValueError(金额必须大于 0) if not category: raise ValueError(分类不能为空) with sqlite3.connect(self.db_path) as conn: cur conn.execute( INSERT INTO expense (amount, category, note) VALUES (?, ?, ?), (amount, category, note), ) return cur.lastrowid def list_all(self): # 按时间倒序返回全部记录 with sqlite3.connect(self.db_path) as conn: rows conn.execute( SELECT id, amount, category, note, created_at FROM expense ORDER BY id DESC ).fetchall() return rows def total(self): # 空表时 SUM 返回 NULL统一转成 0 with sqlite3.connect(self.db_path) as conn: row conn.execute( SELECT SUM(amount) FROM expense ).fetchone() return row[0] if row[0] else 0这段代码的逻辑说明每个方法内部自己开连接、自己关连接with sqlite3.connect()保证了连接关闭和事务提交add()方法里对金额和分类做了业务校验任何入口调用它都会被这道检查拦住这就是 4.3 要展开讲的“校验归属”list_all()返回的是元组列表元组顺序和 SELECT 语句里的列顺序一致View 层通过下标取值。参数说明db_path默认指向db.sqlite3单元测试时可以改成:memory:使用内存数据库amount在 Controller 层已经转成 float所以 Model 里直接做大小判断不再关心字符串解析。3.3 View层模板只做渲染不碰统计和查询View 层的模板里不应该出现sum、count、字符串拼接等逻辑计算。所有数据都应该是 Controller 传过来的现成变量模板只负责把它放进 HTML 对应位置。!-- views/list.html -- !DOCTYPE html html head meta charsetutf-8 title记账 Demo/title /head body h2总支出{{ total }} 元/h2 form methodPOST action/add 金额input typetext nameamount 分类input typetext namecategory 备注input typetext namenote button typesubmit提交/button /form ul {% for r in records %} li{{ r[2] }}{{ r[1] }} 元备注 {{ r[3] }}/li {% endfor %} /ul /body /html这里{{ total }}和{{ r[1] }}是 Jinja2 模板的取值语法用来输出 Controller 传进来的数据。{% for %}循环只做展示没有做求和没有调用数据库也没有导入模块。如果你发现模板里开始写{% set total total r[1] %}或者出现了过滤器里做复杂格式化说明逻辑漏到 View 层了——这种代码最难测试改需求时也最容易漏改。3.4 Controller层校验参数、调Model、决定返回哪个ViewController 是三层里唯一的调度入口它做五件事接参、类型预检、调 Model、把异常转成错误提示、选 View。业务规则不写在 Controller 里SQL 更不写页面拼接也不写。# app.py from flask import Flask, request, render_template, redirect, url_for from models import ExpenseModel app Flask(__name__) model ExpenseModel() app.route(/) def list_expenses(): records model.list_all() total model.total() # Controller 只负责组合数据然后把数据交给模板 return render_template(list.html, recordsrecords, totaltotal) app.route(/add, methods[POST]) def add_expense(): # 类型和空值检查放在 Controller amount request.form.get(amount, typefloat) category request.form.get(category, ).strip() note request.form.get(note, ).strip() if amount is None: return 金额必须是数字, 400 try: model.add(amount, category, note) except ValueError as e: # Model 抛出的业务规则异常转成 HTTP 错误提示 return str(e), 400 # 提交后重定向避免用户刷新页面时重复提交 return redirect(url_for(list_expenses)) if __name__ __main__: app.run(debugTrue, port5000)参数说明request.form.get(amount, typefloat)是 Flask 提供的类型转换写法用户输入非数字时返回None所以 Controller 里只判断None不判断 0——大小判断属于业务规则已经下沉到model.add()里了。redirect(url_for(list_expenses))是 Post/Redirect/Get 模式的经典写法不让浏览器在刷新时重复提交表单。debugTrue会在代码出错时显示调试页生产环境必须改成debugFalse。3.5 跑起来的最小命令与验证路径依赖只有 Flask 一个库安装后直接启动。pip install flask python app.py浏览器访问http://127.0.0.1:5000/按照下面三步验证 MVC 是否各司其职。第一次打开时页面显示“总支出0 元”没有记录这证明 View 正常渲染、Model 正常建表表单里填金额 12.5、分类“餐饮”、备注“午饭”点提交页面跳转回首页首页出现一条记录“餐饮12.5 元备注午饭”总支出变成 12.5这证明控制器接到了参数、模型成功入库、模板正确展示了数据。如果 5000 端口被占用把app.run(port5000)改成其他端口页面访问地址跟着改即可。注意SQLite 文件db.sqlite3是首次启动自动生成的删除它可以清空数据重新开始不影响代码逻辑。4. 前后端分离场景下的MVC变体JSON视图与API控制器4.1 传统MVC到API场景要调整的三件事现在很多项目不再由服务器渲染 HTML而是后端只出 JSON前端用框架自行渲染。这种场景下 MVC 的骨架还在但三个角色要调整一下View 从“服务器模板”降级为“JSON 数据结构”Controller 从返回 HTML 变成返回 JSON 加状态码校验变成两层前端负责体验层的即时提示后端负责数据底线。调整后的对应关系是Controller 仍然接收 HTTP 请求、解析参数、调 Model、返回响应只是响应体换成了jsonify的结果Model 完全不变它本来就不关心数据给到谁View 层被拆成两部分返回给前端的 JSON 由前端负责渲染服务端只保证结构正确。这个变体在现在的工作里反而比传统模板渲染更常见。4.2 改造成Ajax版Controller返回JSON替代HTML在原有代码基础上新增两个路由不动已有的 HTML 页面这就是 MVC 的可扩展性——同一个 Model 同时服务传统页面和 API数据操作没有任何重复。# app.py 中新增的 API 路由 from flask import jsonify app.route(/api/expenses) def api_list(): records model.list_all() # 元组转字典前端拿 JSON 语义更清楚 return jsonify([ { id: r[0], amount: r[1], category: r[2], note: r[3], created_at: r[4], } for r in records ]) app.route(/api/expenses, methods[POST]) def api_add(): # 前端以 JSON 格式提交而不是表单格式 data request.get_json(forceTrue) amount float(data.get(amount, 0)) category data.get(category, ).strip() note data.get(note, ).strip() try: model.add(amount, category, note) except ValueError as e: return jsonify({error: str(e)}), 400 return jsonify({ok: True}), 201对应前端请求代码fetch(/api/expenses, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ amount: 12.5, category: 餐饮, note: 午饭 }) }) .then(res res.json()) .then(data { if (data.ok) { loadExpenses(); // 重新拉取列表 } else { alert(data.error); } });jsonify会自动设置Content-Type: application/json并把 Python 的字典和列表转成 JSON 字符串。状态码 201 表示资源创建成功比一律返回 200 更规范前端也能据此区分“成功”和“新建成功”的场景。forceTrue表示即使请求头没带Content-Type: application/json也强行按 JSON 解析本地调试方便但生产环境建议不写这个参数让非法请求直接返回 415 错误反而更容易暴露问题。4.3 数据校验归属问题Model还是Controller说了算这是 MVC 里最容易产生分歧的地方。我的划分标准是参数能不能转成数字、字段是不是 None这类“类型和空值检查”放 Controller金额必须大于 0、分类必须存在于合法列表里这类“业务规则”放 Model。理由很简单Controller 是入口但入口不止一个——以后可能加命令行脚本、加定时任务、加另一个内部接口它们都可能绕过这个 Controller却绕不过 Model 的add()方法。如果把“金额大于 0”写在 Controller将来新增一个 API 或者一个导入 Excel 的脚本时很容易漏掉这道检查脏数据就进库了。把规则放在 Model 的add()方法里所有入口都必须经过同一个关卡。你也可以理解为Controller 保证“请求能进来”Model 保证“数据进门之前是干净的”。5. MVC落地避坑5条真实踩坑记录与排查路径5.1 Controller越写越肥SQL和业务逻辑混进路由现象Controller 里先拆参数然后直接拼 SQL 字符串查完库再手动拼 HTML 返回给前端整个路由函数七八十行看着像一团乱线。原因项目刚起步时图省事所有逻辑都往路由回调里堆因为它是请求入口需求改到哪里就加到哪里等页面多起来每个路由都复制一份同样的 SQL改表结构时漏改一处问题才暴露。解决把所有 SQL 收进 Model 层的方法里把所有 HTML 拼接收进 View 模板里。Controller 只保留五件事接参、类型预检、调 Model、异常转状态码、选 View。判断标准是任何一个 Controller 方法超过 30 行就该检查是不是有职责越界了。5.2 View模板里做统计改一次需求翻三层文件现象模板里出现{% set total total r[1] %}或者循环里调用带逻辑的过滤器页面显示倒是正常但数据稍微复杂一点就开始乱。原因写模板时嫌 Controller 里多加一个变量麻烦想着“这里顺手就算出来了”。短期看省事长期看模板里的逻辑没法做单元测试也没法复用换一个页面要重新算一遍。解决统一规则是模板只接收“已经算好”的数据。总额在 Model 的total()方法里计算Controller 把它传进模板模板里只做循环和取值。我现在的习惯是模板文件里搜索set和带括号的表达式搜到就说明逻辑漏下去了立即上提。5.3 Model反向依赖View循环依赖让改动处处连环爆现象Model 方法里直接返回render_template(list.html, records...)的结果甚至直接调用了redirect()。改一次前端样式Model 跟着改改一次查询逻辑模板也跟着动两边互相牵连。原因写的时候觉得“反正这个数据只给这个页面用”就把页面渲染也塞进了 Model。这与 MVC 的单向依赖完全相反——Model 本该不认识 View现在它反而决定了 View 的内容。解决Model 层禁止导入任何 Flask 渲染相关的东西只返回 list、dict、int 这类纯数据。Controller 拿到数据后再由它决定用模板还是 JSON 包装。检查方法是在models.py顶部搜索flask搜到就是犯界了。5.4 过度分层小项目套大厂架构一个字段改动牵连五处现象一个总共五六个页面的项目目录套了 Controller、Service、DAO、Repository、Entity 五层改一个字段要从数据库映射一路改到 Controller中间任何一个文件漏改接口就挂。原因把“分层”当成工程完善度的标志以为层数越多项目越正规没考虑抽象成本。这也是 MVC 被误解最深的一个方向——MVC 本身就是为了控制复杂度而不是制造复杂度。解决小项目让 Model 同时承担数据访问和业务规则两个职责等真的出现“两个模块共用同一套业务逻辑”时再把公共部分抽成 Service 层。抽象的正确时机是重复出现两次以上第一次出现叫冗余第二次出现才叫共性。5.5 校验规则两头写漏改一处线上才暴露现象表单提交入口校验了金额大于 0API 入口没有校验结果一批负数金额的数据通过接口进库报表对不上了。原因校验规则没有唯一归属每个入口各写各的新人接手时不知道哪份才是最新的规则。解决业务规则全部收进 Model 层的方法入口。Controller 只做类型转换和空值检查不碰业务规则Model 统一抛ValueErrorController 负责把它转成 400 响应。这样即使新增十个入口校验逻辑也只有一份。报错症状优先排查层确认方法SQL 报错、字段对不上Model搜索.execute(是否全在 models.py页面数据错乱、样式缺失View打开模板看是否出现逻辑计算参数为 None、类型转换报错Controller在路由入口打印request.form结果改动一处引发连环报错依赖方向检查 models.py 是否导入了 flask 相关模块6. 让MVC案例真正可维护三个自查技巧与排查顺序6.1 接口契约化给每层定义“什么进什么出”Model 层的方法应该像接口一样稳定入参是什么类型、返回值是什么类型在方法顶部用注释写死。比如add()的契约是“入参amount: floatcategory: strnote: str出参id: int规则违反时抛ValueError”。Controller 调用它时不需要关心内部 SQL只管拿到结果往后走将来内部从 SQLite 换到 MySQL只要契约不变调用方一行都不用改。这个习惯能让分层在项目变大时依然可控。6.2 目录即文档让命名把边界说出来目录结构和命名本身就是文档。Model 层文件名用models.py路由函数名和 URL 保持直接对应比如/api/expenses对应的函数就叫api_expenses。新成员接手时看到一个 URL 就能顺着函数名找到 Controller、顺着 Controller 里的model.前缀找到 Model 方法、顺着返回的模板名找到 View。如果某个命名对不上了通常说明边界已经歪了需要重构。6.3 报错定位法异常按层判断MVC 项目报错后先看堆栈里第一个项目内文件是哪一层。models.py里的异常绝大多数是 SQL 写错或字段名对不上app.py里的异常多半是参数解析失败或调用顺序有问题模板抛出来的异常则说明 Controller 没有把数据传全。处理顺序建议从 Model 层开始往上游排查因为数据层错了Controller 和 View 拿到的都是脏数据往上查只会浪费时间。我最早写 MVC 时也翻过车把 SQL 直接写在路由里一次改需求连带改三个文件改了半个月才意识到分层不是为了好看是为了让改动只落在一处。后来我习惯在动手前先问自己一句这个改动应该改哪一层如果答案说不清楚多半是前面代码已经把边界写糊了。希望这篇能帮你少走一圈弯路把 MVC 这套骨架真正搭稳。本文还有配套的精品资源点击获取
简介这是一套演示MVC三层架构的Java Web应用案例代码面向正在学习Java Web分层设计、需要理解Controller/Servlet与Model/MyBatis配合方式的开发者项目以具体业务功能为主线涵盖从前端表单到数据库访问的完整请求链路适合作为课程设计或毕业设计的前期参考。资源共121个文件压缩包约6.86MB其中32个java源文件对应各层核心逻辑29个xml文件用于MyBatis映射与Maven工程管理9个jsp和3个html页面构成视图层另有properties、css等配置文件与样式表源码和编译后的class文件一并提供便于对照阅读和排错。项目围绕brand-demo模块展开用户通过HTML表单和JavaScript发起交互Servlet作为控制器接收请求并调用业务处理再由MyBatis执行MySQL数据操作最终把结果交给JSP渲染输出完整呈现了从页面到数据库再回到页面的MVC处理闭环。目前已有1703人学习下载可用它搭建本地运行环境、观察各层代码依赖关系快速建立对MVC与Java Web技术栈的整体认识。1. MVC三层架构被误读最多的地方Model不是数据表三层不是三个包很多刚开始写业务系统的同学看到“MVC三层架构”这个提法会以为它就是把代码放进 models、views、controllers 三个文件夹里真动手的时候又容易把所有 SQL 都塞进路由回调里跑通一遍就觉得自己已经会了。这套理解不是 MVC只是目录长得像。MVC 三层架构真正说的是模型 Model 只负责数据和业务规则视图 View 只负责把数据渲染出来控制器 Controller 只负责接请求、调模型、选视图三者之间单向依赖谁也别越界。这篇我用一份能直接跑起来的最小记账 Demo把典型 MVC 案例拆开讲清楚——代码很短但职责边界、参数校验、常见踩坑全在里面。适合刚开始接触后端分层的开发者也适合已经写过几天业务代码、但总觉得 Controller 越写越乱的人。2. 先立住概念三个角色各自管什么请求路径怎么走2.1 一次HTTP请求在MVC里的完整流转路径一个 MVC 请求的标准路径是固定的。用户在前端页面发起操作浏览器把 HTTP 请求发给服务器服务器里的路由表先匹配 URL命中后把请求转给对应的控制器方法。控制器先做参数预检再调用模型的方法模型去数据库读取或写入数据然后把结果原样返回给控制器控制器拿到结果后决定“渲染哪个视图”或者“重定向到哪个 URL”视图只做模板填充把控制器传过来的数据变成 HTML 返回给浏览器。拿我们马上要写的记账 Demo 举例用户提交一笔支出POST 请求到达/add。控制器的add_expense方法接住表单参数调用ExpenseModel.add()让它把记录插入 SQLite 数据库插入成功后控制器返回一个重定向到首页浏览器收到重定向后再次发起 GET/请求控制器调用list_all()和total()拿到记录列表和总金额传给模板模板循环渲染出页面。这个过程中每个角色只有一件事可做。控制器不写 SQL不做 HTML 拼接不算总额模型只操作数据库不关心页面长什么样视图只做展示不在模板里做统计。任何一个请求你都能沿着“路由 → 控制器 → 模型 → 控制器 → 视图”这条链把它讲完这就是 MVC 最容易理解、也最不容易跑偏的检查方式。2.2 MVC与三层架构的本质区别一个管职责一个管整体切分“MVC 三层架构”这个说法经常被混用实际它是两套维度叠在一起。MVC 关注的是一个请求处理过程中代码职责怎么划分三层架构关注的是整个系统按纵向怎么切成表现层、业务层、数据层。MVC 里的 Controller 和 View 都属于表现层Model 则覆盖了业务层和数据层的大部分内容。对比维度MVC三层架构关注点单个请求的职责分配整个系统的纵向层级最小单元模型 / 视图 / 控制器表现层 / 业务层 / 数据层常见落地一个模块内部的代码组织整个工程从上到下的结构我一般写小型业务系统时直接让 Model 承担数据访问和业务规则两件事Controller 承担表现层的调度View 只做渲染。等项目里 Model 超过 200 行、出现多个模块共享同一套业务逻辑时再把 Model 里偏业务规则的部分拆成独立的 Service 层这时候就变成了“三层架构里面的 MVC”。如果你一上来就把 Controller、Service、DAO 全部分好小项目很容易被抽象拖垮这个坑第 5 章会重点讲。2.3 项目到多大规模才值得上MVC有同学问是不是所有项目都该套 MVC我的判断标准是三条。第一条同一份数据要同时供给网页和接口时如果没有 Model 层两个路由各写一份 SQL改一次表结构要改两处地方漏改一处线上就翻车。第二条多个页面共用同一类数据操作把 SQL 抽成 Model 方法后一次修改全局生效。第三条Controller 开始出现超过三五十行的趋势说明视图调度和业务逻辑已经混在一起了不拆迟早要乱。反过来项目只有三个页面、几个接口、全部代码不到 500 行硬套 MVC 反而会增加负担。最典型的现象是改一个字段要打开五个文件先改数据库、再改 Model、再改 Controller、再改模板、再改测试。这种情况下我建议先不建目录保持线性代码等真的出现重复逻辑再抽。MVC 是为了应对“复杂度增长”的不是为了装饰工程结构。3. 最小可运行案例用Flask写一个MVC记账Demo3.1 为什么用Flask而不是Spring Boot来演示MVC选 Flask 不是因为 Python 比 Java 好而是因为 Flask 的 MVC 边界最直白路由函数天然就是 ControllerJinja2 模板就是 View普通 Python 类就是 Model。整个过程没有任何注解、依赖注入、容器管理的干扰你能一眼看清数据在哪进去、从哪出来。Java 背景的读者做一次映射就能对齐这里的ExpenseModel对应你熟悉的 DAOapp.py里的路由方法对应 Servlet 或 SpringMVC 的 Controllerlist.html对应 JSP 或 Thymeleaf 模板。完整项目只需要三个文件加一个数据库文件结构如下demo/ ├── app.py # 入口同时是 Controller 层 ├── models.py # Model 层封装全部数据库操作 ├── views/ │ └── list.html # View 层只做渲染 └── db.sqlite3 # SQLite 数据库首次运行自动生成提示目录名字叫 views 只是工程习惯和三层架构里的“表现层”不是一个概念别混着记。3.2 Model层四个方法封装全部SQL对外只暴露数据操作Model 层的原则是所有 SQL 都收在模型内部外部调用者只知道“我要添加一笔记录”“我要拿全部记录”“我要算总额”不关心数据库是 SQLite 还是 MySQL。这样将来换数据库或者改表结构只改这一个文件就够了。# models.py import sqlite3 class ExpenseModel: Model 层只负责数据读写不包含 HTTP 相关逻辑 def __init__(self, db_pathdb.sqlite3): self.db_path db_path self._init_table() def _init_table(self): # 建表操作幂等重复执行不会报错 with sqlite3.connect(self.db_path) as conn: conn.execute( CREATE TABLE IF NOT EXISTS expense ( id INTEGER PRIMARY KEY AUTOINCREMENT, amount REAL NOT NULL, category TEXT NOT NULL, note TEXT DEFAULT , created_at TEXT DEFAULT CURRENT_TIMESTAMP) ) def add(self, amount, category, note): # 业务规则统一在这里把关谁调用都绕不过 if not amount or amount 0: raise ValueError(金额必须大于 0) if not category: raise ValueError(分类不能为空) with sqlite3.connect(self.db_path) as conn: cur conn.execute( INSERT INTO expense (amount, category, note) VALUES (?, ?, ?), (amount, category, note), ) return cur.lastrowid def list_all(self): # 按时间倒序返回全部记录 with sqlite3.connect(self.db_path) as conn: rows conn.execute( SELECT id, amount, category, note, created_at FROM expense ORDER BY id DESC ).fetchall() return rows def total(self): # 空表时 SUM 返回 NULL统一转成 0 with sqlite3.connect(self.db_path) as conn: row conn.execute( SELECT SUM(amount) FROM expense ).fetchone() return row[0] if row[0] else 0这段代码的逻辑说明每个方法内部自己开连接、自己关连接with sqlite3.connect()保证了连接关闭和事务提交add()方法里对金额和分类做了业务校验任何入口调用它都会被这道检查拦住这就是 4.3 要展开讲的“校验归属”list_all()返回的是元组列表元组顺序和 SELECT 语句里的列顺序一致View 层通过下标取值。参数说明db_path默认指向db.sqlite3单元测试时可以改成:memory:使用内存数据库amount在 Controller 层已经转成 float所以 Model 里直接做大小判断不再关心字符串解析。3.3 View层模板只做渲染不碰统计和查询View 层的模板里不应该出现sum、count、字符串拼接等逻辑计算。所有数据都应该是 Controller 传过来的现成变量模板只负责把它放进 HTML 对应位置。!-- views/list.html -- !DOCTYPE html html head meta charsetutf-8 title记账 Demo/title /head body h2总支出{{ total }} 元/h2 form methodPOST action/add 金额input typetext nameamount 分类input typetext namecategory 备注input typetext namenote button typesubmit提交/button /form ul {% for r in records %} li{{ r[2] }}{{ r[1] }} 元备注 {{ r[3] }}/li {% endfor %} /ul /body /html这里{{ total }}和{{ r[1] }}是 Jinja2 模板的取值语法用来输出 Controller 传进来的数据。{% for %}循环只做展示没有做求和没有调用数据库也没有导入模块。如果你发现模板里开始写{% set total total r[1] %}或者出现了过滤器里做复杂格式化说明逻辑漏到 View 层了——这种代码最难测试改需求时也最容易漏改。3.4 Controller层校验参数、调Model、决定返回哪个ViewController 是三层里唯一的调度入口它做五件事接参、类型预检、调 Model、把异常转成错误提示、选 View。业务规则不写在 Controller 里SQL 更不写页面拼接也不写。# app.py from flask import Flask, request, render_template, redirect, url_for from models import ExpenseModel app Flask(__name__) model ExpenseModel() app.route(/) def list_expenses(): records model.list_all() total model.total() # Controller 只负责组合数据然后把数据交给模板 return render_template(list.html, recordsrecords, totaltotal) app.route(/add, methods[POST]) def add_expense(): # 类型和空值检查放在 Controller amount request.form.get(amount, typefloat) category request.form.get(category, ).strip() note request.form.get(note, ).strip() if amount is None: return 金额必须是数字, 400 try: model.add(amount, category, note) except ValueError as e: # Model 抛出的业务规则异常转成 HTTP 错误提示 return str(e), 400 # 提交后重定向避免用户刷新页面时重复提交 return redirect(url_for(list_expenses)) if __name__ __main__: app.run(debugTrue, port5000)参数说明request.form.get(amount, typefloat)是 Flask 提供的类型转换写法用户输入非数字时返回None所以 Controller 里只判断None不判断 0——大小判断属于业务规则已经下沉到model.add()里了。redirect(url_for(list_expenses))是 Post/Redirect/Get 模式的经典写法不让浏览器在刷新时重复提交表单。debugTrue会在代码出错时显示调试页生产环境必须改成debugFalse。3.5 跑起来的最小命令与验证路径依赖只有 Flask 一个库安装后直接启动。pip install flask python app.py浏览器访问http://127.0.0.1:5000/按照下面三步验证 MVC 是否各司其职。第一次打开时页面显示“总支出0 元”没有记录这证明 View 正常渲染、Model 正常建表表单里填金额 12.5、分类“餐饮”、备注“午饭”点提交页面跳转回首页首页出现一条记录“餐饮12.5 元备注午饭”总支出变成 12.5这证明控制器接到了参数、模型成功入库、模板正确展示了数据。如果 5000 端口被占用把app.run(port5000)改成其他端口页面访问地址跟着改即可。注意SQLite 文件db.sqlite3是首次启动自动生成的删除它可以清空数据重新开始不影响代码逻辑。4. 前后端分离场景下的MVC变体JSON视图与API控制器4.1 传统MVC到API场景要调整的三件事现在很多项目不再由服务器渲染 HTML而是后端只出 JSON前端用框架自行渲染。这种场景下 MVC 的骨架还在但三个角色要调整一下View 从“服务器模板”降级为“JSON 数据结构”Controller 从返回 HTML 变成返回 JSON 加状态码校验变成两层前端负责体验层的即时提示后端负责数据底线。调整后的对应关系是Controller 仍然接收 HTTP 请求、解析参数、调 Model、返回响应只是响应体换成了jsonify的结果Model 完全不变它本来就不关心数据给到谁View 层被拆成两部分返回给前端的 JSON 由前端负责渲染服务端只保证结构正确。这个变体在现在的工作里反而比传统模板渲染更常见。4.2 改造成Ajax版Controller返回JSON替代HTML在原有代码基础上新增两个路由不动已有的 HTML 页面这就是 MVC 的可扩展性——同一个 Model 同时服务传统页面和 API数据操作没有任何重复。# app.py 中新增的 API 路由 from flask import jsonify app.route(/api/expenses) def api_list(): records model.list_all() # 元组转字典前端拿 JSON 语义更清楚 return jsonify([ { id: r[0], amount: r[1], category: r[2], note: r[3], created_at: r[4], } for r in records ]) app.route(/api/expenses, methods[POST]) def api_add(): # 前端以 JSON 格式提交而不是表单格式 data request.get_json(forceTrue) amount float(data.get(amount, 0)) category data.get(category, ).strip() note data.get(note, ).strip() try: model.add(amount, category, note) except ValueError as e: return jsonify({error: str(e)}), 400 return jsonify({ok: True}), 201对应前端请求代码fetch(/api/expenses, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ amount: 12.5, category: 餐饮, note: 午饭 }) }) .then(res res.json()) .then(data { if (data.ok) { loadExpenses(); // 重新拉取列表 } else { alert(data.error); } });jsonify会自动设置Content-Type: application/json并把 Python 的字典和列表转成 JSON 字符串。状态码 201 表示资源创建成功比一律返回 200 更规范前端也能据此区分“成功”和“新建成功”的场景。forceTrue表示即使请求头没带Content-Type: application/json也强行按 JSON 解析本地调试方便但生产环境建议不写这个参数让非法请求直接返回 415 错误反而更容易暴露问题。4.3 数据校验归属问题Model还是Controller说了算这是 MVC 里最容易产生分歧的地方。我的划分标准是参数能不能转成数字、字段是不是 None这类“类型和空值检查”放 Controller金额必须大于 0、分类必须存在于合法列表里这类“业务规则”放 Model。理由很简单Controller 是入口但入口不止一个——以后可能加命令行脚本、加定时任务、加另一个内部接口它们都可能绕过这个 Controller却绕不过 Model 的add()方法。如果把“金额大于 0”写在 Controller将来新增一个 API 或者一个导入 Excel 的脚本时很容易漏掉这道检查脏数据就进库了。把规则放在 Model 的add()方法里所有入口都必须经过同一个关卡。你也可以理解为Controller 保证“请求能进来”Model 保证“数据进门之前是干净的”。5. MVC落地避坑5条真实踩坑记录与排查路径5.1 Controller越写越肥SQL和业务逻辑混进路由现象Controller 里先拆参数然后直接拼 SQL 字符串查完库再手动拼 HTML 返回给前端整个路由函数七八十行看着像一团乱线。原因项目刚起步时图省事所有逻辑都往路由回调里堆因为它是请求入口需求改到哪里就加到哪里等页面多起来每个路由都复制一份同样的 SQL改表结构时漏改一处问题才暴露。解决把所有 SQL 收进 Model 层的方法里把所有 HTML 拼接收进 View 模板里。Controller 只保留五件事接参、类型预检、调 Model、异常转状态码、选 View。判断标准是任何一个 Controller 方法超过 30 行就该检查是不是有职责越界了。5.2 View模板里做统计改一次需求翻三层文件现象模板里出现{% set total total r[1] %}或者循环里调用带逻辑的过滤器页面显示倒是正常但数据稍微复杂一点就开始乱。原因写模板时嫌 Controller 里多加一个变量麻烦想着“这里顺手就算出来了”。短期看省事长期看模板里的逻辑没法做单元测试也没法复用换一个页面要重新算一遍。解决统一规则是模板只接收“已经算好”的数据。总额在 Model 的total()方法里计算Controller 把它传进模板模板里只做循环和取值。我现在的习惯是模板文件里搜索set和带括号的表达式搜到就说明逻辑漏下去了立即上提。5.3 Model反向依赖View循环依赖让改动处处连环爆现象Model 方法里直接返回render_template(list.html, records...)的结果甚至直接调用了redirect()。改一次前端样式Model 跟着改改一次查询逻辑模板也跟着动两边互相牵连。原因写的时候觉得“反正这个数据只给这个页面用”就把页面渲染也塞进了 Model。这与 MVC 的单向依赖完全相反——Model 本该不认识 View现在它反而决定了 View 的内容。解决Model 层禁止导入任何 Flask 渲染相关的东西只返回 list、dict、int 这类纯数据。Controller 拿到数据后再由它决定用模板还是 JSON 包装。检查方法是在models.py顶部搜索flask搜到就是犯界了。5.4 过度分层小项目套大厂架构一个字段改动牵连五处现象一个总共五六个页面的项目目录套了 Controller、Service、DAO、Repository、Entity 五层改一个字段要从数据库映射一路改到 Controller中间任何一个文件漏改接口就挂。原因把“分层”当成工程完善度的标志以为层数越多项目越正规没考虑抽象成本。这也是 MVC 被误解最深的一个方向——MVC 本身就是为了控制复杂度而不是制造复杂度。解决小项目让 Model 同时承担数据访问和业务规则两个职责等真的出现“两个模块共用同一套业务逻辑”时再把公共部分抽成 Service 层。抽象的正确时机是重复出现两次以上第一次出现叫冗余第二次出现才叫共性。5.5 校验规则两头写漏改一处线上才暴露现象表单提交入口校验了金额大于 0API 入口没有校验结果一批负数金额的数据通过接口进库报表对不上了。原因校验规则没有唯一归属每个入口各写各的新人接手时不知道哪份才是最新的规则。解决业务规则全部收进 Model 层的方法入口。Controller 只做类型转换和空值检查不碰业务规则Model 统一抛ValueErrorController 负责把它转成 400 响应。这样即使新增十个入口校验逻辑也只有一份。报错症状优先排查层确认方法SQL 报错、字段对不上Model搜索.execute(是否全在 models.py页面数据错乱、样式缺失View打开模板看是否出现逻辑计算参数为 None、类型转换报错Controller在路由入口打印request.form结果改动一处引发连环报错依赖方向检查 models.py 是否导入了 flask 相关模块6. 让MVC案例真正可维护三个自查技巧与排查顺序6.1 接口契约化给每层定义“什么进什么出”Model 层的方法应该像接口一样稳定入参是什么类型、返回值是什么类型在方法顶部用注释写死。比如add()的契约是“入参amount: floatcategory: strnote: str出参id: int规则违反时抛ValueError”。Controller 调用它时不需要关心内部 SQL只管拿到结果往后走将来内部从 SQLite 换到 MySQL只要契约不变调用方一行都不用改。这个习惯能让分层在项目变大时依然可控。6.2 目录即文档让命名把边界说出来目录结构和命名本身就是文档。Model 层文件名用models.py路由函数名和 URL 保持直接对应比如/api/expenses对应的函数就叫api_expenses。新成员接手时看到一个 URL 就能顺着函数名找到 Controller、顺着 Controller 里的model.前缀找到 Model 方法、顺着返回的模板名找到 View。如果某个命名对不上了通常说明边界已经歪了需要重构。6.3 报错定位法异常按层判断MVC 项目报错后先看堆栈里第一个项目内文件是哪一层。models.py里的异常绝大多数是 SQL 写错或字段名对不上app.py里的异常多半是参数解析失败或调用顺序有问题模板抛出来的异常则说明 Controller 没有把数据传全。处理顺序建议从 Model 层开始往上游排查因为数据层错了Controller 和 View 拿到的都是脏数据往上查只会浪费时间。我最早写 MVC 时也翻过车把 SQL 直接写在路由里一次改需求连带改三个文件改了半个月才意识到分层不是为了好看是为了让改动只落在一处。后来我习惯在动手前先问自己一句这个改动应该改哪一层如果答案说不清楚多半是前面代码已经把边界写糊了。希望这篇能帮你少走一圈弯路把 MVC 这套骨架真正搭稳。本文还有配套的精品资源点击获取
