Frodo的第一个版本已经实现了,在下一个版本前,我将目前的开发思路整理成三篇文章,分别是数据篇、通信篇、异步篇。
项目地址
Frodo
简要系统分析
数据库设计是紧跟需求来的,在我本科学UML时,数据库设计是在需求分析和系统分析之后,架构设计之前的设计。但博客项目的需求比较简单,主要大需求:
- 内容管理(文章、用户、标签、评论、反馈、动态的增删改查)
- 管理员用户的验证、评论人用户的验证
- 小功能:边栏组件、归档、分类等
再简单地做一个系统分析:
- 博客前台页面(不需要认证,内容展示)
- 博文内容
- 博客作者
- 标签
- 访问量
- 管理页面(需要登录认证进行内容管理)
- 动态页面(需要认证)
- 评论(访问者需要登录认证)
接下来的工作就是根据功能需求设计前后台API,一般如果你是全栈自己开发的话,API形式可以随意些,因为后续还可以灵活调整。如果需要和前端同事合作的话,你需要严格按照restful风格编写,接口的参数、命名、方法和返回体的构造上严格体现需求。
API 格式理应最大化地体现功能需求
前后台API的形式也取决于所用技术,Frodo前台页面是选择模板渲染的,后台是使用Vue, 那么模板就可以在页面上编程,可以实时决定上下文,可以不事先指定。
后台API
url | method | params | response | info |
---|---|---|---|---|
api/posts | GET | limit:1 page: 页面数 with_tag |
{‘items’: [post.*.,], ‘total’: number} | 查询Posts 需要登录 |
api/posts/new | POST | FormData title slug summary content is_page can_comment author_id status |
x | x |
api/post/<post_id> | GET/PUT/DELETE | x | items.*.created_at items.*.author_id items.*.slug items.*.id items.*.title items.*.type items.*._pageview items.*.summary status items.*.can_comment items.*.author_name items.*.tags.* total |
需要登录 |
api/users | GET | x | {‘items’:[user.*.,], ‘total’: num} | 需要登录 |
api/user/new | POST | FormData active name password avatar: avatar.png |
x | 需要登录 |
api/user/<user_id> | GET/PUT | x | user.created_at user.avatar user.id user.active user.email user.name user.url(/user/3/) ok (true) |
需要登录 |
api/upload | POST/OPTIONS | x | x | na |
api/user/search | GET | name | items.*.id items.*.name |
需要登录 |
api/tags | GET | x | items.*.name | 需要登录 |
api/user/info | GET | user (token) | user{‘name’, ‘avartar’} | 相当于current_user |
api/get_url_info | POST | url | x | na |
api/status | POST | text, url, fids = [“png”, …] | r, msg, activity.id, activity.layout, activity.n_comments, activity.n_likes, activity.created_at, activity.can_comment, activity.attachments.*.layout, activity.attachments.*.url, activity.attachments.*.title, activity.attachments.*.size |
数据库设计
设计数据库就是设计表、表字段、表关系。严格上要先绘制E-R模型图,他金石停留在逻辑层面的关系图。下一步根据E-R图,结合使用的数据库类型(关系、Nosql、KV还是图数据库)设计表关系图,随后要考虑如下几个方面:
- 数据存储在哪里?
- 小型记录数据存储在mysql (查询较快)
- 长数据如「博客内容」查询较慢 适合存储在内存数据库
- 分布式还是单一式存储?
- 那些是高频使用数据?
- 经常需要做查询的
- 需要经常累加、统计计算的
- 经常不变化的
- 持久化方案
- 数据库如何定期备份?
- KV数据库的过期策略、定期存储策略
其实博客项目很多都不需要考虑,但再大的项目这些都需要考虑了。其实还应该考虑的是数据库并发访问的问题,这涉及到锁与同步机制,这部分我再通信
部分阐述。
思考过上述问题后,大致有如下图形:
上图中不同的颜色字段考虑了不同的特点,分别是:
- 数据库存储,选用mysql
- KV存储,选用redis
- 高频字段项,需要缓存选用redis或memcached
ORM类设计模式
ORM 是简化SQL操作的产物,python将其做的最好的就是Django
框架,主要做两件事:
- 类到数据库表的映射(通过改造元类实现,达到创建这些_类_时便有了
table
属性,注意不是类实例) - 提供简化的面向对象的sql操作接口
表结构与表迁移
表结构在类中体现,Frodo使用的sqlalchemy
是采用Column()
类的形式。在类比较多是,建议先写一个_基类_,规定共有字段,在会面还可以规定共有方法。