search

4.1 设计模式与架构模式

铺垫了这么久，今天开始我们就要进入正式的开发环节来。 话不多说，从最核心的提示词开始，我们先解决后端的接口。

始终要记得，我们前面已经提到的先要处理“第一条数据是从哪里来的”这个问题。

我们现在先设定一个小目标：编写添加一条提示词的功能。

动手前，先来两个概念：设计模式和架构模式。

hashtag
4.1.1 设计模式与MVC

在 1994 年，四人帮（全拼 Gang of Four）合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用的面向对象软件元素） 的书，该书首次提到了软件开发中设计模式的概念。两个核心点：

  • 对接口编程而不是对实现编程。

  • 优先使用对象组合而不是继承。

而设计模式的经典代表MVC (Model-View-Controller)模式，无论在什么语言里都是一个常见的设计模式，用于组织代码以实现可维护和可扩展的架构。

  1. Model（模型）:

    • 模型负责管理程序的数据和业务逻辑。

    • 在Go中，模型通常通过结构体和接口来实现，并可能与数据库或其他数据源进行交互。

    • 模型层提供了数据的存取、验证和转换等功能，它是与业务逻辑直接相关的部分。

type User struct {
    ID        string
    Name      string
    Email     string
}

func (u *User) Save() error {
    // 保存用户数据到数据库
    // ...
    return nil
}

  1. View（视图）:

    • 视图负责用户界面的展示，它用于生成用户界面并呈现数据。

    • 在基于Go的Web开发中，视图通常通过模板引擎来实现，如html/template或text/template。

  1. Controller（控制器）:

    • 控制器接收用户的输入，并调用模型和视图来完成用户的请求。

    • 在Go中，控制器通常通过HTTP处理函数或者路由处理函数来实现。控制器负责解析用户的请求，调用模型来处理数据，并通过视图来生成用户界面。

以上片是在Go中MVC模式的简单地实现。使用Go的一些流行的Web框架，如Gin或Echo，可以进一步简化和优化MVC架构的实现。

hashtag
4.1.2 架构模式与前后端分离

架构模式（Architectural Pattern）是软件架构中在给定环境下，针对常遇到的问题的、通用且可重用的解决方案。类似于前文所提到的设计模式但覆盖范围更广。

前后端分离的架构模式属于分层架构和模块化设计，分层架构属于软件架构设计领域的架构模式。它是一种垂直的系统层次划分方式,通常包括表示层、业务层、数据访问层等。使得软件系统在垂直方向上保持结构清晰、组件职责明确。

而模块化设计属于软件设计领域的代码组织方式。它是一种水平的系统划分方式,将系统划分为功能明确、相对独立的模块。有利于代码的复用和维护。

这两者在软件设计中通常会同时采用,既关注系统的垂直层次划分,也注重水平方向的模块化拆分,从不同粒度引导软件设计。它们相辅相成,共同推动代码的复用、逻辑清晰和维护性。

我们来看一下基于gin-vue-admin的后端代码目录结构：

（详细描述见附录4。）

在前端代码作为视图层(见前文MVC模式)分离后，后端代码又可以分为4层：

  • 路由层（Router）: 负责路由的定义和请求的分发。

  • 控制器层（API）: 负责处理具体的请求，通常会调用服务层的逻辑。

  • 服务层（Service）: 负责具体的业务逻辑处理，通常会调用模型层来进行数据处理。

  • 模型层（Model）: 负责数据的存储和检索，与数据库交互。

在这样的架构中，所有和数据库交互的操作全部在模型层中完成，这样在上层只需要调用接口，告诉模型我需要怎样的数据，以及筛选条件，不需要关心数据是存在MySQL里，或者是Redis中，抑或者是已经被迁移到了MongoDB。

我们现在就先来为提示词建立一个数据表和对应的模型：

如果项目很复杂，还可以独立出DAO层，它可以：

  • 提高代码复用性：DAO 层可以对数据库操作进行封装，提高代码复用性。我个人很讨厌业务中的各种复制粘贴，这种项目的后期维护成本非常高，经常会出现莫名其妙的问题。

  • 解耦业务逻辑和数据库操作：DAO 层负责与数据库交互，将数据库操作与业务逻辑分离，可以使业务逻辑更简洁、易于维护。

  • 提高代码可测试性：DAO 层的代码可以单独进行测试，提高代码可测试性。

你如果有过更换数据源，或者要为某些查询逻辑进行修改的经历，那你就知道同一套逻辑在不同地方复制粘贴时要修改时的痛苦。而封装这些接口，只需要管理传入参数和返回参数，中间的整个过程都不需要业务层去考虑，非常适合团队协作，避免出现屎山代码。

当然，因为我们项目的复杂度相对较低，所以可以直接在上层封装Service层。

这一层是可以封装较为复杂的业务逻辑的，它跟数据库无关，而跟业务有关，关心的是某个具体的业务的实现。而在其上的控制器(Controller)相对而言就更不关系数据村在哪里，而是关心数据从哪里来，

这样最简单的实现就完成了。 我们只需要加入路由，让其能被访问就好。

当然，如果想要简化Http请求，只用GET和POST其实也足够了，删除和修改不使用DELETE和PUT，而使用POST请求也是没有问题的。

Previous第四天 核心逻辑编写Next4.2 数据模型的扩充处理

Last updated