Go语言进阶之Go语言高性能Web框架Iris项目实战-项目结构优化EP05
ccwgpt 2025-06-09 20:31 11 浏览 0 评论
前文再续,上一回我们完成了用户管理模块的CURD(增删改查)功能,功能层面,无甚大观,但有一个结构性的缺陷显而易见,那就是项目结构过度耦合,项目的耦合性(Coupling),也叫耦合度,进而言之,模块之间的关系,是对项目结构中各模块间相互联系紧密程度的一种量化。耦合的强弱取决于模块间调用的复杂性、调用模块之间的方式以及通过函数或者方法传送数据对象的多少。模块间的耦合度是指模块之间的依赖关系,包括包含关系、控制关系、调用关系、数据传递关系以及依赖关系。项目模块的相互依赖越多,其耦合性越强,同时表明其独立性越差,愈加难以维护。
项目结构优化
目前IrisBlog项目的问题就是独立性太差,截至目前为止,项目结构如下:
.
├── README.md
├── assets
│ ├── css
│ │ └── style.css
│ └── js
│ ├── axios.js
│ └── vue.js
├── favicon.ico
├── go.mod
├── go.sum
├── main.go
├── model
│ └── model.go
├── mytool
│ └── mytool.go
├── tmp
│ └── runner-build
└── views
├── admin
│ └── user.html
├── index.html
└── test.html
一望而知,前端页面(views)以及静态文件(assets)的工程化尚可,不再需要进行分层操作,但是在后端,虽然模型层(model.go)和工具层(mytool.go)已经分离出主模块,但主要业务代码还是集中在入口文件main.go中:
package main
import (
"IrisBlog/model"
"IrisBlog/mytool"
"fmt"
"github.com/jinzhu/gorm"
_ "github.com/jinzhu/gorm/dialects/mysql"
"github.com/kataras/iris/v12"
)
func main() {
db, err := gorm.Open("mysql", "root:root@(localhost)/irisblog?charset=utf8mb4&parseTime=True&loc=Local")
if err != nil {
fmt.Println(err)
panic("无法连接数据库")
}
fmt.Println("连接数据库成功")
//单数模式
db.SingularTable(true)
// 创建默认表
db.AutoMigrate(&model.User{})
// 逻辑结束后关闭数据库
defer func() {
_ = db.Close()
}()
app := newApp(db)
app.HandleDir("/assets", iris.Dir("./assets"))
app.Favicon("./favicon.ico")
app.Listen(":5000")
}
func newApp(db *gorm.DB) *iris.Application {
app := iris.New()
tmpl := iris.HTML("./views", ".html")
// Set custom delimeters.
tmpl.Delims("${", "}")
// Enable re-build on local template files changes.
tmpl.Reload(true)
app.RegisterView(tmpl)
app.Delete("/admin/user_action/", func(ctx iris.Context) {
ID := ctx.URLParamIntDefault("id", 0)
db.Delete(&model.User{}, ID)
ret := map[string]string{
"errcode": "0",
"msg": "删除用户成功",
}
ctx.JSON(ret)
})
app.Put("/admin/user_action/", func(ctx iris.Context) {
ID := ctx.PostValue("id")
Password := ctx.PostValue("password")
user := &model.User{}
db.First(&user, ID)
user.Password = mytool.Make_password(Password)
db.Save(&user)
ret := map[string]string{
"errcode": "0",
"msg": "更新密码成功",
}
ctx.JSON(ret)
})
app.Post("/admin/user_action/", func(ctx iris.Context) {
username := ctx.PostValue("username")
password := ctx.PostValue("password")
fmt.Println(username, password)
md5str := mytool.Make_password(password)
user := &model.User{Username: username, Password: md5str}
res := db.Create(user)
if res.Error != nil {
fmt.Println(res.Error)
ret := map[string]string{
"errcode": "1",
"msg": "用户名不能重复",
}
ctx.JSON(ret)
return
}
ret := map[string]string{
"errcode": "0",
"msg": "ok",
}
ctx.JSON(ret)
})
return app
}
入口文件main.go承载了太多业务,既需要负责数据库结构体的创建,又得操心模板的渲染和接口逻辑的编写,说白了:泥沙俱下,沉渣泛起。
事实上,像这样把所有代码都堆到一个文件中,还会带来协作问题,比如,当你花了一整天的时间,好不容易完成了一段业务逻辑,也通过了本地测试,准备第二天提交线上测试,但是第二天上班时却发现这个逻辑莫名其妙地开始报错了,这通常是因为有同事在你走后修改了你编写或者依赖的那个模块,归根结底,并不完全是协作的问题,项目结构也是因素之一。
多个研发同时修改了同一个源代码文件。虽然在规模相对较小、人员较少的项目中,这种问题或许并不严重,但是随着项目的增长,研发人员的增加,这种每天早上刚上班时都要经历一遍的痛苦就会越来越多,甚至会严重到让有的团队在长达数周的时间内都不能发布一个稳定的项目版本,因为每个人都在不停地修改自己的代码,以适应其他人所提交的变更,周而复始,恶性循环。
所以我们必须把业务单独抽离出来,比如用户管理其实是后台模块功能,只有特定的管理员才可能在其页面进行操作,所以我们可以单独创建一个控制层:
mkdir handler
cd hanler
随后编写后台控制逻辑admin.go:
package handler
import (
"github.com/kataras/iris/v12"
)
//用户管理页面模板
func Admin_user_page(ctx iris.Context) {
ctx.View("/admin/user.html")
}
这里把用户管理页面的解析函数单独抽离在handler包中,注意函数的首字母要进行大写处理,因为首字母小写函数是私有函数,只能在包内使用,无法被别的包调用。
随后改造入口文件main.go逻辑:
app.Get("/admin/user/", handler.Admin_user_page)
路由匹配时,只需要引入handler包中的Admin_user_page函数就可以了。
随后,对路由进行分组优化,同属一个业务的模块绑定在同一个分组中:
adminhandler := app.Party("/admin")
{
adminhandler.Use(iris.Compression)
adminhandler.Get("/user/", handler.Admin_user_page)
adminhandler.Get("/userlist/", handler.Admin_userlist)
adminhandler.Delete("/user_action/", handler.Admin_userdel)
adminhandler.Put("/user_action/", handler.Admin_userupdate)
adminhandler.Post("/user_action/", handler.Admin_useradd)
}
如此,业务和路由解析就彻底分开了,结构体创建函数也清爽了不少:
func newApp(db *gorm.DB) *iris.Application {
app := iris.New()
tmpl := iris.HTML("./views", ".html")
tmpl.Delims("${", "}")
tmpl.Reload(true)
app.RegisterView(tmpl)
adminhandler := app.Party("/admin")
{
adminhandler.Use(iris.Compression)
adminhandler.Get("/user/", handler.Admin_user_page)
adminhandler.Get("/userlist/", handler.Admin_userlist)
adminhandler.Delete("/user_action/", handler.Admin_userdel)
adminhandler.Put("/user_action/", handler.Admin_userupdate)
adminhandler.Post("/user_action/", handler.Admin_useradd)
}
return app
}
数据层结构优化
业务层进行了拆分,但是数据层还集成在入口文件中main.go:
package main
import (
"IrisBlog/handler"
"IrisBlog/model"
"fmt"
"github.com/jinzhu/gorm"
_ "github.com/jinzhu/gorm/dialects/mysql"
"github.com/kataras/iris/v12"
)
func main() {
db, err := gorm.Open("mysql", "root:root@(localhost)/irisblog?charset=utf8mb4&parseTime=True&loc=Local")
if err != nil {
fmt.Println(err)
panic("无法连接数据库")
}
fmt.Println("连接数据库成功")
//单数模式
db.SingularTable(true)
// 创建默认表
db.AutoMigrate(&model.User{})
// 逻辑结束后关闭数据库
defer func() {
_ = db.Close()
}()
app := newApp(db)
app.HandleDir("/assets", iris.Dir("./assets"))
app.Favicon("./favicon.ico")
app.Listen(":5000")
}
这里的含义是,一旦进入入口逻辑,就立刻初始化数据库,随后执行业务代码,当业务执行完毕后,利用延迟函数defer关闭数据库链接。
这种逻辑的弊端是,一旦数据库服务挂掉,整个项目服务也会受影响,再者,很多纯静态化页面并不需要数据库链接,每一次都链接数据库,显然是画蛇添足。
所以单独建立数据包:
mkdir database
cd database
建立数据层逻辑database.go:
package database
import (
"IrisBlog/model"
"fmt"
"github.com/jinzhu/gorm"
_ "github.com/jinzhu/gorm/dialects/mysql"
)
func Db() *gorm.DB {
db, err := gorm.Open("mysql", "root:root@(localhost)/irisblog?charset=utf8mb4&parseTime=True&loc=Local")
if err != nil {
fmt.Println(err)
panic("无法连接数据库")
}
fmt.Println("连接数据库成功")
//单数模式
db.SingularTable(true)
// 创建默认表
db.AutoMigrate(&model.User{})
return db
}
这里我们构建函数Db(),它返回一个数据库操作的结构体指针,专门用来执行数据库操作,需要注意的是,删除函数内之前的延后defer关闭链接函数,否则链接在函数体内就关闭了,调用方就无法使用数据库了。
调用上,直接调用database包中的Db(),就可以直接使用数据库指针了:
//用户列表接口
func Admin_userlist(ctx iris.Context) {
db := database.Db()
var users []model.User
res := db.Find(&users)
// 逻辑结束后关闭数据库
defer func() {
_ = db.Close()
}()
ctx.JSON(res)
}
随后,继续优化入口文件:
package main
import (
"IrisBlog/handler"
"github.com/kataras/iris/v12"
)
func main() {
app := newApp()
app.HandleDir("/assets", iris.Dir("./assets"))
app.Favicon("./favicon.ico")
app.Listen(":5000")
}
func newApp() *iris.Application {
app := iris.New()
tmpl := iris.HTML("./views", ".html")
tmpl.Delims("${", "}")
tmpl.Reload(true)
app.RegisterView(tmpl)
adminhandler := app.Party("/admin")
{
adminhandler.Use(iris.Compression)
adminhandler.Get("/user/", handler.Admin_user_page)
adminhandler.Get("/userlist/", handler.Admin_userlist)
adminhandler.Delete("/user_action/", handler.Admin_userdel)
adminhandler.Put("/user_action/", handler.Admin_userupdate)
adminhandler.Post("/user_action/", handler.Admin_useradd)
}
}
这里优化了main函数,使其逻辑更加简明和清晰。
最后,优化数据层逻辑database.go:
package database
import (
"IrisBlog/model"
"fmt"
"github.com/jinzhu/gorm"
_ "github.com/jinzhu/gorm/dialects/mysql"
_ "github.com/jinzhu/gorm/dialects/sqlite"
)
const db_type int = 1
func sqlite3() *gorm.DB {
db, err := gorm.Open("sqlite3", "/tmp/IrisBlog.db")
if err != nil {
fmt.Println(err)
panic("无法连接数据库")
}
fmt.Println("连接sqlite3数据库成功")
return db
}
func mysql() *gorm.DB {
db, err := gorm.Open("mysql", "root:root@(localhost)/irisblog?charset=utf8mb4&parseTime=True&loc=Local")
if err != nil {
fmt.Println(err)
panic("无法连接数据库")
}
fmt.Println("连接mysql数据库成功")
return db
}
func Db() *gorm.DB {
switch db_type {
case 0:
db := mysql()
//单数模式
db.SingularTable(true)
// 创建默认表
db.AutoMigrate(&model.User{})
return db
case 1:
db := sqlite3()
//单数模式
db.SingularTable(true)
// 创建默认表
db.AutoMigrate(&model.User{})
return db
default:
panic("未知的数据库")
}
}
这里我们分别封装mysql和sqlite3数据库指针函数,然后通过switch语句来根据不同的开发环境而进行切换和控制。
至此,项目结构的首次结构性优化就完成了,优化后的结构如下:
├── README.md
├── assets
│ ├── css
│ │ └── style.css
│ └── js
│ ├── axios.js
│ └── vue.js
├── database
│ └── database.go
├── favicon.ico
├── go.mod
├── go.sum
├── handler
│ └── admin.go
├── main.go
├── model
│ └── model.go
├── mytool
│ └── mytool.go
├── tmp
│ └── runner-build
└── views
├── admin
│ └── user.html
├── index.html
└── test.html
结语
为什么我们一开始不直接采用低耦合高内聚的项目架构?因为别人的经验并不是我们的经验,只有真正经历过才是真实的开发经验,项目开发没有标准答案,只有选择,然后承担后果,只有尝试过苦涩的果实之后,下一次才会做出正确的选择。该项目已开源在Github:
https://github.com/zcxey2911/IrisBlog ,与君共觞,和君共勉。
相关推荐
- 一个基于.Net Core遵循Clean Architecture原则开源架构
-
今天给大家推荐一个遵循CleanArchitecture原则开源架构。项目简介这是基于Asp.netCore6开发的,遵循CleanArchitecture原则,可以高效、快速地构建基于Ra...
- AI写代码翻车无数次,我发现只要提前做好这3步,bug立减80%
-
写十万行全是bug之后终于找到方法了开发"提示词管理助手"新版本那会儿,我差点被bug整崩溃。刚开始两周,全靠AI改代码架构,结果十万行程序漏洞百出。本来以为AI说没问题就稳了,结果...
- OneCode低代码平台的事件驱动设计:架构解析与实践
-
引言:低代码平台的事件驱动范式在现代软件开发中,事件驱动架构(EDA)已成为构建灵活、松耦合系统的核心范式。OneCode低代码平台通过创新性的注解驱动设计,将事件驱动理念深度融入平台架构,实现了业务...
- 国内大厂AI插件评测:根据UI图生成Vue前端代码
-
在IDEA中安装大厂的AI插件,打开ruoyi增强项目:yudao-ui-admin-vue31.CodeBuddy插件登录腾讯的CodeBuddy后,大模型选择deepseek-v3,输入提示语:...
- AI+低代码技术揭秘(二):核心架构
-
本文档介绍了为VTJ低代码平台提供支持的基本架构组件,包括Engine编排层、Provider服务系统、数据模型和代码生成管道。有关UI组件库和widget系统的信息,请参阅UI...
- GitDiagram用AI把代码库变成可视化架构图
-
这是一个名为gitdiagram的开源工具,可将GitHub仓库实时转换为交互式架构图,帮助开发者快速理解代码结构。核心功能一键可视化:替换GitHubURL中的"hub...
- 30天自制操作系统:第六天:代码架构整理与中断处理
-
1.拆开bootpack.c文件。根据设计模式将对应的功能封装成独立的文件。2.初始化pic:pic(可编程中断控制器):在设计上,cpu单独只能处理一个中断。而pic是将8个中断信号集合成一个中断...
- AI写代码越帮越忙?2025年研究揭露惊人真相
-
近年来,AI工具如雨后春笋般涌现,许多人开始幻想程序员的未来就是“对着AI说几句话”,就能轻松写出完美的代码。然而,2025年的一项最新研究却颠覆了这一期待,揭示了一个令人意外的结果。研究邀请了16位...
- 一键理解开源项目:两个自动生成GitHub代码架构图与说明书工具
-
一、GitDiagram可以一键生成github代码仓库的架构图如果想要可视化github开源项目:https://github.com/luler/reflex_ai_fast,也可以直接把域名替换...
- 5分钟掌握 c# 网络通讯架构及代码示例
-
以下是C#网络通讯架构的核心要点及代码示例,按协议类型分类整理:一、TCP协议(可靠连接)1.同步通信//服务器端usingSystem.Net.Sockets;usingTcpListene...
- 从复杂到优雅:用建造者和责任链重塑代码架构
-
引用设计模式是软件开发中的重要工具,它为解决常见问题提供了标准化的解决方案,提高了代码的可维护性和可扩展性,提升了开发效率,促进了团队协作,提高了软件质量,并帮助开发者更好地适应需求变化。通过学习和应...
- 低代码开发当道,我还需要学习LangChain这些框架吗?| IT杂谈
-
专注LLM深度应用,关注我不迷路前两天有位兄弟问了个问题:当然我很能理解这位朋友的担忧:期望效率最大化,时间用在刀刃上,“不要重新发明轮子”嘛。铺天盖地的AI信息轰炸与概念炒作,很容易让人浮躁与迷茫。...
- 框架设计并不是简单粗暴地写代码,而是要先弄清逻辑
-
3.框架设计3.框架设计本节我们要开发一个UI框架,底层以白鹭引擎为例。框架设计的第一步并不是直接撸代码,而是先想清楚设计思想,抽象。一个一个的UI窗口是独立的吗?不是的,...
- 大佬用 Avalonia 框架开发的 C# 代码 IDE
-
AvalonStudioAvalonStudio是一个开源的跨平台的开发编辑器(IDE),AvalonStudio的目标是成为一个功能齐全,并且可以让开发者快速使用的IDE,提高开发的生产力。A...
- 轻量级框架Lagent 仅需20行代码即可构建自己的智能代理
-
站长之家(ChinaZ.com)8月30日消息:Lagent是一个专注于基于LLM模型的代理开发的轻量级框架。它的设计旨在简化和提高这种模型下代理的开发效率。LLM模型是一种强大的工具,可以...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- 框架图 (58)
- flask框架 (53)
- quartz框架 (51)
- abp框架 (47)
- springmvc框架 (49)
- 分布式事务框架 (65)
- scrapy框架 (56)
- shiro框架 (61)
- 定时任务框架 (56)
- java日志框架 (61)
- mfc框架 (52)
- abb框架断路器 (48)
- beego框架 (52)
- java框架spring (58)
- grpc框架 (65)
- tornado框架 (48)
- 前端框架bootstrap (54)
- orm框架有哪些 (51)
- 知识框架图 (52)
- ppt框架 (55)
- 框架图模板 (59)
- 内联框架 (52)
- cad怎么画框架 (58)
- ssm框架实现登录注册 (49)
- oracle字符串长度 (48)