注意事项

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

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

  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{} 类型。