注意事项
虽然框架提供的泛型类型极大提高的开发的简便性,但对于业务模型来说应当慎重使用(不能滥用),因为泛型类型将会掩盖真实的数据类型,这对于业务项目长期维护来说弊大于利,特别是复杂的业务项目。业务模型的数据类型定义应当尽可能地明确、有意义、不可变,才有利于编译型语言在编译阶段做类型检查和优化、有利于业务后续长期维护。
举个例子,以下是社区热心小伙伴提供的真实业务模型案例:
type MiDispatchData struct {
Status *g.Var `json:"status"`
BrandId *g.Var `json:"brand_id"`
AreaId *g.Var `json:"area_id"`
Year *g.Var `json:"year"`
Month *g.Var `json:"month"`
Day *g.Var `json:"day"`
Hour *g.Var `json:"hour"`
RequestTime *g.Var `json:"request_time"`
Source *g.Var `json:"source"`
BikeId *g.Var `json:"bike_id"`
BikeType *g.Var `json:"bike_type"`
Lon *g.Var `json:"lon"`
Lat *g.Var `json:"lat"`
SiteId *g.Var `json:"site_id"`
BikeMac *g.Var `json:"bike_mac"`
}
虽然这样的做法程序也能正常运行,业务场景也能正常覆盖。但却丢失了编译型语言的编译器优势(这就类似于PHP变量了),在后期项目维护时很难再确定字段的数据类型。
使用建议
- 泛型在基础组件、中间件项目中使用较多。
- 如果字段在业务场景中有多重含义、类型,那么可以使用泛型代替如
interface{}
类型。