#云开发高阶实战任务总结# 投票系统的解析与设计

DNSPod x 云开发CloudBase 联合特惠

免运维更省事，低成本快速打造生动的站点应用

云开发活动详情：https://cloudbase.net/community/activities/db9f2d6c5eefa7d20034247749f1879c.html

任务解析

模拟操作流程

1. 在比赛开始前，观众看到前台提示“暂未开始”；
2. 管理员进入后台，添加选手信息，开启比赛；前台自动更新提示文字；
3. 后台选择一位选手并通知前台展示信息；前台自动显示选手信息；
4. 后台开启该选手的投票；前台自动开始计时并允许投票；
5. 投票结束后，前台自动停止计时并禁止投票；后台可查看投票情况；
6. 循环步骤 3 至步骤 5；
7. 后台关闭比赛。

再加亿点点细节

• 阶段五的“用户验证开关”可解读为：当开关关闭时，新观众也可随时进入投票；当开关开启时，观众必须有向之前选手投票的记录，才能对当前选手投票。然而，至于是要求全程都参与过投票才可以，还是之前参与过至少一次投票即可，任务详情中并没有明确的要求。从实现上来说，后者比前者简单。
• 能否在一开始即将“用户验证开关”打开？
• 后台的投票列表（显示向特定选手投了支持或反对票的用户）是否需要实时刷新？
• 前台是否有必要显示选手的投票结果？
• ……

设计

数据结构

config 集合 用于存储系统的配置信息。系统的总开关status和用户验证开关participation是肯定要有的，还需要“有明确表示当前选手的标志” 即cand_id。对倒计时来说，投票结束的时间可以和选手绑定，也可以不绑定。如果不绑定，则加入第四个配置项expiry。

candidate 集合 用于存储选手信息。字段包括姓名name、简介intro、照片photo 等。

vote 集合 用于存储投票情况。字段包括观众 ID_openid、选手 IDcand_id、投票类型（支持或反对）type 等。

布局

前台一个页面，从上到下依次为：状态栏（暂未开始 / 比赛中）、选手信息（照片、姓名、简介）、投票区（投票状态、计时器、投票按钮）。

后台一个页面，从上到下依次为：状态栏（暂未开始 / 比赛中）、控制区（比赛状态开关、“用户验证开关”）、选手列表（姓名、投票小计）、投票情况（某选手的投票详情）。

数据流

1. 在比赛开始前（config 集合的四个配置项中，两个开关置于 0，选手标记和计时标记清空），观众看到的前台提示“暂未开始”（读取 status）；
2. 管理员进入后台（登录校验），添加选手信息（candidate 集合新增一条记录，其中 photo 字段为照片在云存储中的 fileID），开启比赛（status 置 1）；前台自动更新提示文字（读取 status）；
3. 后台选择一位选手并通知前台展示信息（配置项 cand_id 值设置为 candidate 集合中响应选手的 ID）；前台自动显示选手信息（“通知”即为监听并获取选手信息，云存储 getTempFileURL() ）；
4. 后台开启该选手的投票（配置 expiry 值为从现在开始 45 秒之后）；前台自动开始计时并允许投票（监听并获取 expiry，本地倒计时）；
5. 投票结束后，前台自动停止计时并禁止投票（本地倒计时）；后台可查看投票情况（定时刷新）；
6. 循环步骤 3 至步骤 5；
7. 后台关闭比赛（status 置 0）。

再加亿点点细节

• 云存储和数据库三个集合的权限应如何设置？
• 即便对资源设置了严格的权限，有哪些数据库操作依然是不宜直接在客户端（HTML / JavaScript）代码中进行的？
• 每位选手的投票倒计时结束后，cand_id和expiry是否需要清空？这两个字段究竟应该由谁来维护？
• 45 秒的投票时间中，能否切换“用户验证开关”？
• 是否应该支持对已完成投票的选手再开一次投票？如果支持，原有的投票是否需要清空？
• 任务详情要求刷新前台页面后能实时获取状态，那么后台页面是否也应支持这一特性？
• ……