gin
的路由一般是这样写的。
`
route.GET("/tags",GetTags)
route.GET("/articles",GetArticles)
route.GET("/authors",GetAuthors)
`
这样写的话,意味着 Tags
控制器里的列表,方法名叫 GetTags
,Articles
控制器里的列表功能,叫 GetArticles
, Author
控制器里的列表其方法名叫 GetAuthors
. 有没有办法把他们的方法名统一起来呢,都叫 func Index
或者 func List
不好吗?
另一种方法,是这样。 `
route.GET("/tags",(&Controller.TagsController{}).Index)
route.GET("/articles",(&Controller.ArticlesController{}).Index)
route.GET("/authors",(&Controller.AuthorsController{}).Index)
` 这样,列表方法的名称统一了,
这两种方法,各有什么优劣么?
有疑问加站长微信联系(非本文作者)

简单的才是最好的,下面的那种很明显就是面向对象后遗症,不过也没有什么优劣之分,纯粹看公司领导或者项目要求,通常是上面那种,毕竟函数可以分版本
面对对象没啥不好, 事实上数据载体和业务代码分离不是什么坏事.如果面对对象那么差,go的下一个重大特性就不是泛型的实现了.
第二种看着脑阔都疼
……
我是第一种的爱好者。
第一种其实最主流的是出现在nodejs的框架,比如express里。
他的思路是函数化,也就是每个路由对应一个函数,不过度oop,不是用控制器类,更常见的是在入口函数前堆一堆middleware,用middleware的组合来进行控制
第二种没见过,常见的是直接把一个控制器类传递进去。
一般路径直接和控制器类名/动作名相关。
优点是维护路由,便于继承。
对于动作的过滤/配置,一般依靠控制器的设置,以及控制器类的继承来实现。
两种方式都有各自的优缺点。
第一种更适合做轻量,简单的服务。
第二种适合做基础服务,框架等需要继承的。
go的应用场景更偏第一种。
另外就是你的例子里路由最大的优势,自注释性体现的不明显。
我找点我大概的代码看一下,你就会发现,哪怕我把注释全去了,你也能够在一个文件里大概的了解到这个uri大概做了什么,有那些控制动作。
第二种方式需要看继承树,虽然功能强大,调整简单,但不够直观
另外,再看了遍你的原文。
你原文里的问题,是你对go的思路还不够了解,脑洞也不够。
你完全不该去建立个控制器对象,只需要把代码放在不同的包里面,直接引用包里export出来的action就可所以了。
比如