Golang 分层架构设计实战 ｜ 青训营笔记

Zeergen
1,267 阅读5分钟

这是我参与「第五届青训营 」笔记创作活动的第2天。这一篇文章主要用于记录本次课程实战项目的设计思路，然后简要分析一下在Go语言下分层设计的思想。

经典分层架构思想

经典的MVC框架将各层的功能实现划分开来，各自处理各自的任务，利于业务解耦合，增强了代码的维护性、可读性。其中：

  1. M （Model）- 与数据库交互的数据模型，进行数据相关操作
  2. V （View） - 与用户直接交互的数据区，负责收集展示数据
  3. C （Controller） - 收到请求后，调用Model层同数据库获取数据，将数据以一定格式返回给View层展示给用户，负责接收数据和逻辑处理

当然随着业务以及对应数据愈发复杂，当前流行的实际分层方式【D-V-C+S】：

  1. D （Dao）数据访问层，负责和数据库建立连接，封装对数据库的CURD操作
  2. V （View）视图层，负责与用户交互
  3. C （Controller）控制层，负责接收处理业务的结果，以view视图的形式返回给客户端
  4. S （Service）业务逻辑层，负责业务逻辑处理，计算打包业务实体（entity/model）

Controller和Service的划分是为了更好的控制获取数据的粒度 --> S层处理业务逻辑+C层接收并筛选数据

下面以一个看帖网页为例，分析如何设计一个分层架构。

项目需求分析

以掘金社区话题为例，页面的功能包括话题详情回帖列表，支持回帖，点赞，和回帖回帖，以此为需求模型，开发一个该页面交涉及的服务端小功能。

发帖评论
image.pngimage.png

项目实现一个社区话题页面，包含：

  • 展示话题（标题，文字描述）
  • 和回帖列表
  • 暂不考虑前端页面实现，仅仅实现一个本地wb服务话题和回站数据用文件存诸

基于分层架构具体设计

整体分为三层，dao数据层，servicej逻辑层，controller视图层。

  • 数据层关联底层数据模型，也就是这里的model,封装外部数据的增删改查，我们的数据存储在本地文件，通过文件操作拉取话题，帖子数据：数据层面向逻辑层，对service层透明，屏蔽下游数据差异，也就是不管下游是文件，还是数据库，还是微服务等，对sevⅵce层的接口模型是不变的
  • Servciei逻辑层处理核心业务逻辑，计算打包业务实体model,对应我们的需求，就是话题页面，包括话题和回帖列表，并上送给视图层
  • Controller视图层负责处理和外部的交互逻辑，以view视图的形式返回给客户端，对于我们需求，我们封装json格式化的请求结果，api形式访问

数据层

实体设计

主题和帖子一对多对应

Topic
{
    id: 1
    title: "青训营"
    content: "第五届青训营来啦！"
    create_time: 1650437616
}
Post
{
    id: 1
    parent_id: 1
    content: "这是一篇博客！"
    create_time: 1650437616
}

数据读取

数据层具体设计数据结构如下，为了加快索引使用哈希表提升索引速度。

var (
	topicIndexMap map[int64]*Topic
	postIndexMap  map[int64][]*Post
)

由于数据存储在文件中，数据层的初始化工作涉及到文件读取。 具体代码如下

func Init(filePath string) error {
	open, err := os.Open(filePath + "topic")
	if err != nil {
		return err
	}
	scanner := bufio.NewScanner(open)
	topicTmpMap := make(map[int64]*Topic)
	for scanner.Scan() {
		text := scanner.Text()
		var topic Topic
		if err := json.Unmarshal([]byte(text), &topic); err != nil {
			return err
		}
		topicTmpMap[topic.Id] = &topic
	}
	topicIndexMap = topicTmpMap

	open, err = os.Open(filePath + "post")
	if err != nil {
		return err
	}
	scanner = bufio.NewScanner(open)
	postTmpMap := make(map[int64][]*Post)
	for scanner.Scan() {
		text := scanner.Text()
		var post Post
		if err := json.Unmarshal([]byte(text), &post); err != nil {
			return err
		}
		posts, ok := postTmpMap[post.ParentId]
		if !ok {
			postTmpMap[post.ParentId] = []*Post{&post}
			continue
		}
		posts = append(posts, &post)
		postTmpMap[post.ParentId] = posts
	}
	postIndexMap = postTmpMap
	return nil
}

有了内存索引，下步就是实现查询操作就比较简单了，直接根据查询key获得map中的value就好了，这里用到了sync.once,主要适用高并发的场景下只执行一次的场景，这里的基于once的实现模式就是我们平常说的单例模式，减少存储的浪费。

type Topic struct {
	Id         int64     `gorm:"column:id"`
	Title      string    `gorm:"column:title"`
	Content    string    `gorm:"column:content"`
	CreateTime time.Time `gorm:"column:create_time"`
}

type TopicDao struct {
}

var topicDao *TopicDao
var topicOnce sync.Once

func NewTopicDaoInstance() *TopicDao {
	topicOnce.Do(
		func() {
			topicDao = &TopicDao{}
		})
	return topicDao
}

func (*TopicDao) QueryTopicById(id int64) *Topic {
	return topicIndexMap[id]
}

逻辑层

逻辑层从数据层获取数据，并组装实体，提供给Controller层调用。

type PageInfo struct {
	Topic    *repository.Topic
	PostList []*repository.Post
}

func QueryPageInfo(topicId int64) (*PageInfo, error) {
	return NewQueryPageInfoFlow(topicId).Do()
}

func NewQueryPageInfoFlow(topId int64) *QueryPageInfoFlow {
	return &QueryPageInfoFlow{
		topicId: topId,
	}
}

type QueryPageInfoFlow struct {
	topicId  int64
	pageInfo *PageInfo

	topic   *repository.Topic
	posts   []*repository.Post
}

func (f *QueryPageInfoFlow) Do() (*PageInfo, error) {
	if err := f.checkParam(); err != nil {
		return nil, err
	}
	if err := f.prepareInfo(); err != nil {
		return nil, err
	}
	if err := f.packPageInfo(); err != nil {
		return nil, err
	}
	return f.pageInfo, nil
}

func (f *QueryPageInfoFlow) checkParam() error {
	if f.topicId <= 0 {
		return errors.New("topic id must be larger than 0")
	}
	return nil
}

func (f *QueryPageInfoFlow) prepareInfo() error {
	//获取topic信息
	var wg sync.WaitGroup
	wg.Add(2)
	go func() {
		defer wg.Done()
		topic := repository.NewTopicDaoInstance().QueryTopicById(f.topicId)
		f.topic = topic
	}()
	//获取post列表
	go func() {
		defer wg.Done()
		posts := repository.NewPostDaoInstance().QueryPostByParentId(f.topicId)
		f.posts = posts
	}()
	wg.Wait()
	return nil
}

func (f *QueryPageInfoFlow) packPageInfo() error {
	f.pageInfo = &PageInfo{
		Topic:    f.topic,
		PostList: f.posts,
	}
	return nil
}

可以通过协程来并行执行，加快执行效率。

视图层

视图层定义需要定义一个view对象，来和用户交互。

type PageData struct {
	Code int64       `json:"code"`
	Msg  string      `json:"msg"`
	Data interface{} `json:"data"`
}

func QueryPageInfo(topicIdStr string) *PageData {
	//参数转换
	topicId, err := strconv.ParseInt(topicIdStr, 10, 64)
	if err != nil {
		return &PageData{
			Code: -1,
			Msg:  err.Error(),
		}
	}
	//获取service层结果
	pageInfo, err := service.QueryPageInfo(topicId)
	if err != nil {
		return &PageData{
			Code: -1,
			Msg:  err.Error(),
		}
	}
	return &PageData{
		Code: 0,
		Msg:  "success",
		Data: pageInfo,
	}

}

主函数

在主函数中设置路由，以gin框架为例子。

func main() {
	if err := Init("./data/"); err != nil {
		os.Exit(-1)
	}
	r := gin.Default()
	r.GET("/community/page/get/:id", func(c *gin.Context) {
		topicId := c.Param("id")
		data := cotroller.QueryPageInfo(topicId)
		c.JSON(200, data)
	})
	err := r.Run()
	if err != nil {
		return
	}
}

运行项目，使用curl进行测试，可以看到使用API成功获取了后台数据。

image.png

总结

项目实现了一个经典的分层结构，通过该项目可以对分成架构设计有了一个简单的认识。

avatar
文章
阅读
粉丝