Go的ORM框架GORM最佳实践之不定参数的用法（二）

写在前面

最近一段时间的工作主要以业务逻辑编写为主，重度使用了一些Go的框架，比如Web框架Gin、ORM框架GORM、模板渲染框架Simplate等等。在高强度的情况下编写高复杂度的代码，难免会遇到各种坑，自然而然地也会积累很多宝贵的经验，这些经验是我个人比较看重的，因此总乐意花一些时间总结。

上一篇博客写了在GROM中使用不定参数的技巧，有朋友私信询问，于是感觉有必要基于上一篇内容再续一篇把这个点讲透彻。

适应人群

入门√——初级——中级——高级；本文适应入门及以上。

GORM最佳实践之不定参数的用法（二）

再看GROM中不定参数的最佳实践

承接上一篇博客，看下面的代码：

QueryByUserID QueryByUserIDargsargsQueryByUserID

QueryByUserIDUserID为1

总之，非常灵活！

所述最佳实践中不定参数的约定

QueryByUserID 

首先我们先把这里的约定给出来：

argsargs[0]map[string]interface{}ID=1ID IN (1,2)argsargs[0]map[string]interface{}argsargs[0]stringargs[1:]args[0]"created_at > ? AND deleted_at > ?"args[1:]

GORM中相关函数源码解读

Where函数

WhereWheremap[string]interface{}queryargs

buildCondition 函数

WhereOrNot

其他问题

通过上面的分析可以知道，在Where中传入的不定参数具有一定的约束，第二 、三…个参数不能随便写。

如果期望传入多个查询条件

string"created_at > ? AND deleted_at > ?"

如果期望传入一个函数回调

在我所遇到的应用场景中，还没有传入回调的场景，就个人经验来看，在没有强规范制约时（当前确实想不到一种合适的规范），传入回调会增加函数复杂度，造成后期代码维护困难。

不定参数用在可有可无的搜索条件

推荐不定参数只用在那些可有可无的搜索条件，如果一个函数定义时已经明确知道函数中需要包含哪些参数，推荐把这些参数显式写在函数定义中，利用Go静态语言的特定，减少编码逻辑上的错误。

小结

本文介绍了使用GORM时加入不定参数后的灵活性，以及这种灵活性背后的约束。通过对GORM中 Where函数和 buildCondition函数 源码的分析，更进一步阐释了这种不定参数的应用规范（及其缘由）：

argsargs[0]map[string]interface{}argsargs[0]map[string]interface{}argsargs[0]stringargs[1:]

参考