`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)
`
这样，列表方法的名称统一了，
这两种方法，各有什么优劣么？
……
我是第一种的爱好者。
第一种其实最主流的是出现在nodejs的框架，比如express里。
他的思路是函数化，也就是每个路由对应一个函数，不过度oop，不是用控制器类，更常见的是在入口函数前堆一堆middleware,用middleware的组合来进行控制
第二种没见过，常见的是直接把一个控制器类传递进去。
一般路径直接和控制器类名/动作名相关。
优点是维护路由，便于继承。
对于动作的过滤/配置，一般依靠控制器的设置，以及控制器类的继承来实现。
两种方式都有各自的优缺点。
第一种更适合做轻量，简单的服务。
第二种适合做基础服务，框架等需要继承的。
go的应用场景更偏第一种。
#4
更多评论
简单的才是最好的，下面的那种很明显就是面向对象后遗症，不过也没有什么优劣之分，纯粹看公司领导或者项目要求，通常是上面那种，毕竟函数可以分版本
#1
面对对象没啥不好, 事实上数据载体和业务代码分离不是什么坏事.如果面对对象那么差,go的下一个重大特性就不是泛型的实现了.
#2
今日阅读排行
一周阅读排行