为什么在 GO 中设计 Dao 层时，总是会设计一个interface的接口

好处就是传递的时候可以只限制接口类型，方便测试和无感知替换dao层。 dao层基本就是java转过来的，保留了java的一些习惯

没什么好处 java恶习

因为你不知道你的dao层是不是以后会变成其他的orm ，你现在用的gorm 可能后面用xorm ……

其实可以一个控制器包揽所有的。

这个跟语言无关，这是一种经久不衰很经典的设计模式。这主要是为了解耦实例与实例之间的依赖，抽象一层接口出来，可以让我们去依赖抽象，减少耦合。减少耦合的目的主要有两个，一个是工程化，二一个是可以达到在运行时更换实例的目的。

里氏替换原则

从过往经验的理解区别：

1. 可替换：也就是其他网友提到的，DB 驱动的更换
2. 解决依赖问题：Go包容易出现循环依赖，用这个 interface，基本可以解决这个问题。

java 使用的习惯。 好处就是上面说的，DB替换和依赖问题。

接口，顾名思义就是对外是死的，内部怎么换是自己的事了。

type GoodsDao struct{}

func (d *GoodsDao) QueryGoods(goodsNo string) (*models.Goods, error) {
    //正常商品销售价
    goods:=Query()
    return goods, nil
}

type Goods11Dao struct{}

func (d *Goods11Dao) QueryGoods(goodsNo string) (*models.Goods, error) {
    //正常商品销售价
    goods:=Query()

    //双11活动
    goods=Activity11(goods)
    return goods, nil
}

type Goods51Dao struct{}

func (d *Goods51Dao) QueryGoods(goodsNo string) (*models.Goods, error) {
    //正常商品销售价
    goods:=Query()

    //劳动节活动
    goods=Activity51(goods)
    return goods, nil
}

type IGoodsDao interface {
    QueryGoods(goodsNo string) (*models.Goods, error)
}

var container = map[string]IGoodsDao{
    "0":  &GoodsDao{},
    "11": &Goods11Dao{},
    "51": &Goods51Dao{},
}
var festival string = "0"

func NewGoodsDao() IGoodsDao {
    return container[festival]
}

真实际业务中面向接口编程，是为了应对产品经理和运营人员提到各种恶心需求一种方案， 如上代码 //正常商品销售价 是正常代码 然而运营需要 各种活动价代码 只有中特定几天使用 其它时间都是正常销售价 面向接口 就可以根据festival 节日，调用不同实例。在有节日把节日活动代码加上，没有节日调用正常销售代码。