面向UI编程？
Categories:
程序设计
背景
前两天团队内在做数据库设计评审，其中有个数据库表对应的UI类似下面：
| 分区 | A | B | C |
|---|---|---|---|
| 客厅 | √ | √ | √ |
| 厨房 | √ | √ | |
| 餐厅 | √ | √ | |
| 次卧 | √ | ||
| 天台 | √ | √ |
其中 ABC是同一个层级的东西，并列关系。
小伙伴设计的表就是将这个二维表原样翻译，
create table xxx (
分区 VARCHAR(25),
a VARCHAR(25),
b VARCHAR(25),
c VARCHAR(25)
)
介绍完小伙伴自己也提到这样可能不太好，因为后续一定会出现一些关联查询例如
where type = 'A'
where type in ('A', 'B' )
// 按上面的表设计，关联语句就得写成
where A=true or B=true
如果把表设计成ABC存一个字段就方便做这种关联查询，但是又得把原本的一条记录存成三条记录，所以小伙伴也有点纠结。
| 分区 | 类型 |
|---|---|
| 客厅 | A |
| 客厅 | B |
| 客厅 | C |
| 厨房 | A |
| 厨房 | B |
| 餐厅 | B |
| 餐厅 | C |
| 次卧 | B |
| 天台 | A |
| 天台 | C |
我的观点
我觉得这里的一个核心问题就是，大家往往是面向UI编程，而不是面向逻辑编程。 如果UI改成一棵树状，你又怎样设计呢？
- 客厅
- A
- B
- C
- 厨房
- A
- B
- 餐厅
- B
- C
显然大家的表设计更多是会把ABC改成同一个字段存多行了。
发现没有，你的设计是随着UI的变化而变化的！
我们应该做的是面向逻辑做设计，UI只是一个展现形式而已。
上面这个例子可能因为一些业务背景我不方便说，所以会看着有点云里雾里不以为然。
这不重要。我想表达的核心观点就是，关注逻辑，不要关注UI。
要根据业务逻辑来判断应该是（多个字段存在一行）还是（一个字段存成多行），而不是根据UI来。
面向UI编程往往就是偷懒而已，因为表结构和UI一致的话就直接CRUD就完事了，如果表结构和UI不一致的话还得做一些转化处理。
但其实一来这些数据格式和UI的转换工作没那么复杂，二来UI又不是不能改，也可以给UI提建议让他们改不是吗？
如果你觉得本文对你有帮助或不错，可略表心意，请我喝一杯冰可乐。 ☕
