coeditor/GinSkeleton/docs/low_coupling.md

本篇将探讨主线解耦问题

1.目前项目主线是从路由开始，直接切入到表单参数验证器，验证通过则直接进入了控制器,这里就导致了验证器和控制器之间存在一点低耦合度.
2.如果你追求更低的模块之间的耦合度，接下来我们将对上述问题进行解耦操作.

当前项目代码存在的低耦合逻辑

1.我们以用户删除数据接口为例进行介绍.
2.本文的 41 行就是我们所说验证器与控制器出现了低耦合.

// 1.访问路由
users.POST("delete", validatorFactory.Create(consts.ValidatorPrefix+"UsersDestroy"))


// 2.进入表单参数验证器
type Destroy struct {
	Id float64 `form:"id"  json:"id" binding:"required,min=1"`
}

func (d Destroy) CheckParams(context *gin.Context) {

	if err := context.ShouldBind(&d); err != nil {
		errs := gin.H{
			"tips": "UserDestroy参数校验失败，参数校验失败，请检查id(>=1)",
			"err":  err.Error(),
		}
		response.ErrorParam(context, errs)
		return
	}

	//  该函数主要是将绑定的数据以 键=>值 形式直接传递给下一步（控制器）
	extraAddBindDataContext := data_transfer.DataAddContext(d, consts.ValidatorPrefix, context)
	if extraAddBindDataContext == nil {
		response.ErrorSystem(context, "UserShow表单参数验证器json化失败", "")
        context.Abort()
		return
	} else {
		// 验证完成，调用控制器,并将验证器成员(字段)递给控制器，保持上下文数据一致性
        //  以下代码就是验证器与控制器之间的一点耦合
		(&web.Users{}).Destroy(extraAddBindDataContext)
	}
}

开始解耦

1.针对41行出现的验证器与控制器耦合问题，我们开始解耦

// 1.我们对以上代码进行简单的改造即可实现代码的解耦
// 2.路由首先切入表单参数验证器，将对应的控制器代码写在第二个回调函数即可
// 3.注意：市面上很多框架的中间件等注册的函数都是 "洋葱模型"  ,即函数的回调顺序和注册顺序是相反的，但是gin框架则是按照注册顺序依次执行
users.POST("delete", validatorFactory.Create(consts.ValidatorPrefix+"UsersDestroy"), (&web.Users{}).Destroy)


// 4.代码经过以上改在以后， 从 38 行开始的 else {  ...  }  代码删除即可

解耦以后的注意事项

1.如果业务针对控制器存在比较多的 Aop 切面编程，就会导致路由文件以及 import 显得比较繁重

//  1.例如删除数据之前的和之后的回调
users.POST("delete", 

validatorFactory.Create(consts.ValidatorPrefix+"UsersDestroy"),

(&Users.DestroyBefore{}).Before,   // 控制器Aop的前置回调，例如删除数据之前的权限判断，相关代码可参考 app/aop/users/destroy_before.go
(&web.Users{}).Destroy,           // 控制器逻辑
(&Users.DestroyAfter{}).After   // 控制器Aop的后置回调，例如被删除数据之后的数据备份至history表 ,相关代码可参考 app/aop/users/destroy_after.go 

)

2.对比以上代码，如果你的项目存在较多的 AOP 编程、或者说不同的路由前、后回调函数比较多，不建议进行解耦（毕竟目前就是极低耦合）,否则给路由文件以及 import 部分带来了比较多的负担.
3.如果你的项目路由前后回调函数比较少，建议参考以上代码进行解耦.