注意事项

虽然框架提供的泛型类型极大提高的开发的简便性，但对于业务模型来说应当慎重使用（不能滥用），因为泛型类型将会掩盖真实的数据类型，这对于业务项目长期维护来说弊大于利，特别是复杂的业务项目。业务模型的数据类型定义应当尽可能地明确、有意义、不可变，才有利于编译型语言在编译阶段做类型检查和优化、有利于业务后续长期维护。

举个例子，以下是社区热心小伙伴提供的真实业务模型案例：

  1. type MiDispatchData struct {
  2.     Status      *g.Var `json:"status"`
  3.     BrandId     *g.Var `json:"brand_id"`
  4.     AreaId      *g.Var `json:"area_id"`
  5.     Year        *g.Var `json:"year"`
  6.     Month       *g.Var `json:"month"`
  7.     Day         *g.Var `json:"day"`
  8.     Hour        *g.Var `json:"hour"`
  9.     RequestTime *g.Var `json:"request_time"`
  10.     Source      *g.Var `json:"source"`
  11.     BikeId      *g.Var `json:"bike_id"`
  12.     BikeType    *g.Var `json:"bike_type"`
  13.     Lon         *g.Var `json:"lon"`
  14.     Lat         *g.Var `json:"lat"`
  15.     SiteId      *g.Var `json:"site_id"`
  16.     BikeMac     *g.Var `json:"bike_mac"`
  17. }

虽然这样的做法程序也能正常运行，业务场景也能正常覆盖。但却丢失了编译型语言的编译器优势（这就类似于PHP变量了），在后期项目维护时很难再确定字段的数据类型。

使用建议

  • 泛型在基础组件、中间件项目中使用较多。
  • 如果字段在业务场景中有多重含义、类型，那么可以使用泛型代替如interface{}类型。