📄 一句话概括
界面是人和数据之间的窗口——少打字、防填错、及时反馈;界面上一格,对应表里一列。
📝 本节和前面几节的关系
数据和管家都齐了,本节补上最后一环:真正用数据的人怎么和系统打交道。
一、界面的三件事
输入:让人把数据填进来——输入框给清楚提示,别让人猜格式; 动作:按钮点下去执行一件事——对应后台一条 SQL; 反馈:结果说清楚——成功、失败、为什么失败,都要讲明白。 三件事办妥,界面才算能用——界面是给【人】设计的,不是给机器。
二、校验要在最前面
借书人不能空、日期要合法——校验尽量在界面这一层先做,别等塞进数据库才被约束拦下; 界面校验为了体验(当场提示),数据库约束为了底线(谁也绕不过)——两道闸各管一段; 能少让人打字的地方就少:下拉选项、默认值、自动补全,都是把错误消灭在源头。
三、界面与表的对应
一个输入框通常对应表里的一列,一个提交按钮对应一条 INSERT; 了解这个对应,设计界面时就知道每个控件背后发生什么; 4.7 说过程序靠事件驱动、7.8 说过对象靠消息驱动——界面正是这两者的活样板:点一下鼠标就是一条事件消息。
四、动手 Demo:设计一个登记界面
画一个借阅登记界面,再写出它点下提交后要做三件事。
# 借阅登记: 界面 -> 校验 -> 组装 SQL
def submit(who, book, day):
if not who or not book:
return "提示: 借书人和书名不能空"
return "INSERT INTO loan (who, book, day) VALUES (%s, %s, %s)" % (who, book, day)
print(submit("波仔", "三国演义", "2026-10-14"))
print(submit("", "三国演义", "2026-10-14"))
实跑输出:
--------------------------------------------------------------------
设计用户界面
--------------------------------------------------------------------
数据库最终要给人用, 界面就是人和数据之间的窗口。
一个图书管理的输入界面长这样:
+--------------------------------------+
| 图书借阅登记 |
+--------------------------------------+
| 借书人: [ 波仔 ] |
| 书名 : [ 三国演义 ] |
| 日期 : [ 2026-10-14 ] |
| [ 提交 ] [ 清空 ] |
+--------------------------------------+
提交后系统做的事:
1. 校验: 借书人不能空, 书名不能空
2. 组装: INSERT INTO loan (who, book, day) VALUES (...)
3. 反馈: 界面提示【登记成功】
界面元素 对应什么 设计要点
----------------------------------------------------
输入框 一个数据库列 给提示文字, 别让人猜
提交按钮 一条 SQL 语句 点一下就完成一件事
提示信息 执行结果 成功失败都要说清楚
界面设计的出发点是人: 少打字、防填错、及时反馈。
两次调用演示了界面的两条路:数据齐了组装 SQL,缺了就当场提示——反馈必须及时。 真实界面里这些都在可视化控件后面跑,但骨子里就是【校验→组装→反馈】三步。
30 秒实验
- 给你最常用的一个 App 的某个输入界面,找出它做了哪几条校验。
- 说出界面上一个输入框背后,最终会变成哪条 SQL。
常见误区
- 以为界面只是画得好看——界面的核心是让人少出错、及时得到反馈。
- 以为有界面校验就不用数据库约束——界面能绕开,约束才是最后底线。
自测三问(点开对答案)
1. 界面的三件事? —— 输入、动作、反馈。 2. 界面校验和数据库约束各管什么? —— 界面校验管体验(当场提示),数据库约束管底线(谁也绕不过)。 3. 界面的一个按钮背后通常是什么? —— 一条事件消息,最终变成一条 SQL 语句。- ☐ 下一节(8.8 向DBMS发送CRUD操作的SQL语句)
相关笔记
- LX_CH4_47 — 界面就是事件驱动的活样板
- LX_CH7_78 — 点一下鼠标,就是一条发给对象的消息
- 💻 计算机是怎样跑起来的 · 索引