1 项目简介
本项目设计实现一个类似于知乎问答系统的后端,基本功能为用户对问题、回答进行发布和修改,支持按热度和时间等排序获取问题列表。用户可以对回答进行点赞点踩,同时也可以就回答发表评论,或者回答他人的评论。为了提升用户体验,进阶部分要求问题和回答支持图片的编辑,提供第三方登录和分享功能。
2 项目系统架构
本项目的基于MVC框架模式进行开发。MVC 模式代表 Model-View-Controller(模型-视图-控制器) 模式。使用 MVC 的目的是将M和V的实现代码分离,从而使同一个程序可以使用不同的表现形式,这种模式用于应用程序的分层开发。
- Model(模型) - 模型代表一个存取数据的对象模型。它也可以带有逻辑,在数据变化时更新控制器。
- View(视图) - 视图代表模型包含的数据的可视化。
- Controller(控制器) - 控制器作用于模型和视图上。它控制数据流向模型对象,并在数据变化时更新视图。它使视图与模型分离开。
下图所示为MVC模型关系图。其中,模型层实现系统中的业务逻辑;视图层则用于与用户的交互,通常用JSP来实现;控制层则是模型层和视图层之间沟通的桥梁,它可以把用户的请求分派并选择恰当的视图来显示它 们,同时它也可以解释用户的输入并将其映射为模型层能够执行的操作。
注意框架与设计模式虽然相似,但却有着根本的不同。设计模式是对在某种环境中反复出现的问题以及解决该问题的方案的描述,它比框架更具象;框架可以用代码表示,也能直接执行或复用,而对模式而言只有实例才能用代码表示;设计模式是比框架更小的元素,一个框架中往往含有一个或多个设计模式,框架总是针对某一特定应用领域,但同一模式却可适用于各种应用。可以说,框架是软件,而设计模式是软件的知识。
3 技术选型说明和运行环境
3.1 技术选型
项目使用Golang语言开发,采用主流的go-web后台应用框架gin和MySQL的ORM工具--Gorm。
Gin 是一个 go 写的 web 框架,在后台项目中担当Controller的角色,它具有运行速度快,分组的路由器,良好的崩溃捕获和错误处理,非常好的支持中间件和 json,这些都和 WEB 紧密相关,通过提供这些功能,使开发人员更方便地处理 WEB 业务。
gorm是使用go语言实现数据库访问的ORM库,在后台项目中担当Model的角色。使用这个库,我们可以利用面向对象的方法,更加方便的对数据库中的数据进行CRUD,使开发者只需要关注sql语句本身,而不需要花费精力去处理加载驱动、创建连接、创建statement等繁杂的过程。gorm采用ORM思想解决了实体和数据库映射的问题,对数据库访问进行了封装,屏蔽了api底层访问细节,使我们不用与具体的api打交道,就可以完成对数据库的持久化操作。
下列是具体使用到的组件:
| 名称 | 地址 | 作用 |
|---|---|---|
| gin | https://github.com/gin-gonic/gin | web 框架 |
| gorm | https://github.com/jinzhu/gorm | orm 映射框架 |
| mysql | https://github.com/go-sql-driver/mysql | 数据库 |
| viper | https://github.com/spf13/viper | 配置管理 |
| jwt-go | https://github.com/dgrijalva/jwt-go | jwt 认证 |
| snoyflake | https://github.com/sony/sonyflake | 雪花算法唯一 ID |
| air | https://github.com/cosmtrek/air | 开发热加载 |
| logrus | https://github.com/sirupsen/logrus | 日志处理 |
| bcrypt | https://golang.org/x/crypto/bcrypt | 密码处理 |
| validator | https://github.com/go-playground/validator/v10 | 数据校验 |
3.2 运行环境
我们使用docker容器将项目进行打包部署在ubuntu服务器上。Docker 提供轻量的虚拟化,你能够从Docker获得一个额外抽象层,你能够在单台机器上运行多个Docker微容器,而每个微容器里都有一个微服务或独立应用,例如你可以将Tomcat运行在一个Docker,而MySQL运行在另外一个Docker,两者可以运行在同一个服务器。使用docker可以极大地简化配置,它能让你将环境和配置放入代码然后部署,同样的Docker配置能够在各种环境中使用,这实际是将应用环境和底层环境实现了解耦。同时实现了将应用隔离以及快速部署等好处。
4 软件系统概念原型的多种视图
软件架构涉及到抽象、分解和组合、风格和美学,为了准确具体地描述软件架构模型,我们一般会由多个视图或视角组成的模型来描述软件架构,该方法称为多重视图方法。
使用多个视图的目的:
基于多个并发视图的使用情况来说明描述软件密集型系统架构的模型。
1、使用多个视图允许独立地处理各"风险承担人":最终用户、开发人员、系统工程师、项目经理等所关注的问题,
2、并且能够独立地处理功能性和非功能性需求。
3、一组关键视图搭配起来可以完整地描述一个逻辑自洽的软件架构模型。
一般来说,我们常用的几种视图有分解视图、依赖视图、泛化视图、执行视图、实现视图、部署视图和工作任务分配视图。
4.1 系统功能模块视图
4.2 项目部署视图
4.3 项目逻辑视图
4.4 执行视图
执行视图展示了系统运行时的时序结构特点,比如流程图、时序图等。执行视图中的每一个执行实体,一般称为组件(Component),都是不同于其他组件的执行实体。如果有相同或相似的执行实体那么就把它们合并成一个。
执行实体可以最终分解到软件的基本元素和软件的基本结构,因而与软件代码具有比较直接的映射关系。在设计与实现过程中,我们一般将执行视图转换为伪代码之后,再进一步转换为实现代码。
下面我们对几个关键功能进行执行视图分析:
1、 用户注册过程
2、用户登录过程
3、发布问题
4.5 工作任务分配视图
| 项目组成员 | 学号 | 项目中的分工 |
|---|---|---|
| AAA | SA2022xxxx | 页面设计,前端开发 |
| BBB | SA2022xxxx | 后端xx模块开发,项目开发模块协调 |
| CCC | SA2022xxxx | 后端xx模块开发,性能压测 |
| DDD | SA2022xxxx | 后端xx模块开发,项目部署 |
5 数据库设计
根据UML图我们可以很容易地得出主要类的数据模型,各个表的具体内容如下所示:
- User表
| 字段 | 类型 | 非空 | 注释 |
|---|---|---|---|
| id | bigint | 是 | 用户id |
| name | varchar | 是 | 用户名 |
| nickname | varchar | 是 | 昵称 |
| password | varchar | 是 | 密码 |
| gender | varchar | 否 | 性别 |
| avatar_url | varchar | 否 | 头像图片url |
| description | varchar | 否 | 描述 |
- Question表
| 列名 | 类型 | 非空 | 注释 |
|---|---|---|---|
| id | bigint | 是 | 问题id |
| title | varchar | 是 | 题目 |
| content | varchar | 是 | 内容 |
| created_at | varchar | 是 | 创建时间 |
| update_at | varchar | 否 | 修改时间 |
| user_id | bigint | 是 | 用户id |
- Answer表
| 列名 | 类型 | 注释 |
|---|---|---|
| id | bigint | 回答id |
| content | varchar | 内容 |
| comment_num | bigint | 评论数 |
| agree_num | bigint | 赞同数 |
| tag | varchar | 标签 |
| question_id | bigint | 对应问题id |
| user_id | bigint | 所属用户id |
- Comment表
| 列名 | 类型 | 注释 |
|---|---|---|
| id | bigint | 评论id |
| content | varchar | 内容 |
| agree_num | bigint | 赞同数 |
| reply_id | text | 回复对应的id |
| user_id | int | 所属用户id |
注意各个表的外键依赖表现了类之间的关系!
6 项目的实现视图
- 总的源代码目录结构如下
-qasystem
|-config 项目配置
|-controller 控制器
|-dao 数据库连接
|-middleware 中间件
|-model 数据库模型以及相关操作
|-router 路由配置
|-util 公用工具
|-go.mod 项目依赖
|-initDB.go 数据库初始化文件
|-main.go 程序执行入口
- Controller类:控制层
-
Model类:数据库模型以及相关操作
-
DAO层:负责对数据库的连接和初始化等
-
View层:前端文件
-
配置文件:关于项目的静态配置
7 系统概念原型的核心工作机制
7.1 概念原型的含义
-
概念是人对能代表某种事物或发展过程的特点及意义所形成的思维结论。
-
概念原型是一种虚拟的、理想化的软件产品形式。
7.2 仿知乎问答系统项目的概念原型
用户可以不注册登录而仅以游客身份浏览问答系统,进行账号的注册后方可登录该知乎问答系统,拥有正常用户权限。此后用户可以根据自己需求在系统内进行提问,并可@邀请用户回答;用户可以拉链查询现有的问题(根据时间或者热度等排序)或者根据指定关键词or标签进行问题的检索,然后可以就相关问题进行回答。其他用户可以对别人的回答进行评论,点赞,也可对别人的评论进行点赞和回复。永不可以查看个人浏览问题痕迹和回答列表,以及对个人资料进行修改。