gf gen dao: 希望增加一个参数, 使得生成do结构体的时候, 字段类型都是指针, 而不是interface{}

[smzgl]

希望执行gf gen dao的时候增加一个参数, 比如 --pointer, 使得生成do结构体的时候, 字段类型都是指针, 而不是interface{}. 这样当使用do结构体的时候, 也可以进行字段类型校验.

[lingcoder]

举例：
如果你希望校验 *time.Time，可以在gf gen dao那里配置类型映射。
配置了timestamp 类型映射 time.Time，你生成得do就不是interface{}, 而是time.Time

[smzgl]

举例： 如果你希望校验 *time.Time，可以在gf gen dao那里配置类型映射。 配置了timestamp 类型映射 _time.Time，你生成得do就不是interface{}, 而是_time.Time

这样的话，每个字段都要配置，就比较繁琐。我希望是跟entity类型一样，只不过都是指针。

[lingcoder]

为什么不使用entity.XXX来校验类型呢？

[smzgl]

使用dao.User.ctx.update()的时候，如果只希望更新部分字段（这段字段可能包括空串或者0），使用entity的话，要么更新所有字段，要么不更新零值，要么就要fields指定更新的字段，要么用g.map逐个字段再一次赋值。 前两种不满足需求，后两种方式就很繁琐。

[smzgl]

比如，我在logic设计一个接口，可以更新一个表多个或者一个字段。传入do就很容易实现，一个接口就能满足。 传入entity显然不行，传入g.map又缺乏类型校验。每个字段实现一个函数又很繁琐（tob的业务有很多宽表，几十个字段），自己再声明一个跟entity差不多，但是类型是指针的，也同样繁琐，并且不好维护。

这时候，带有指针类型的do就很有用了。既满足需求，还能满足强类型，还是根据数据库自动生成的。

[lingcoder]

我想说，这个类型校验其实没什么必要，因为假如你传错了，数据库也会告诉你。如果你将interface{}改成具体类型的指针，反而多了很多限制。id我可以传字符串/数值/uuid都可以，如果明确类型反而要显式转换。还有时间，支持很多格式的字符串，你换成*time.Time后，只能明确转换。而且*time.Time这种也是go官方不推荐的用法。

[lingcoder]

参数的校验放在controller层就做掉了，dao层没有必要这样。

[smzgl]

实际上，这就是强类型和弱类型的区别。update接口参数是强类型的时候，一方面可以清晰知道传什么数据。框架和数据库对很多数据做了兼容或者转换。

举个例子，数据字段是varchar，传入gtime.time 和传入time.time ，数据库存储的字符串大概率是不同的。

因为update的接口，入参各个字段是any，其他开发者不一定清楚any应该传什么类型，只能靠运行时才能发现。

强类型的好处，就是可以让问题在编译期发现，而不是推迟到运行时。

至于赋值类型转换的问题，我想这就是选择问题。类似前端开发选择ts还是js。所以希望代码生成增加一个选项，可以让希望使用强类型的有一个选择。

[smzgl]

参数的校验放在controller层就做掉了，dao层没有必要这样。

会存在一些service接口是其他地方使用，不是只是controller才用到。

[lingcoder]

用g.Validator(). 校验
还可以注册自定义规则

[smzgl]

我的述求是service的接口可以使用一个字段以及类型和entity一样，但是都是指针的结构体作为 service接口的入参，以让调用方知道需要传入什么类型的参数，而不是校验字段值是否合法。

[smzgl]

想象一下，一个宽表有50多个字段，除了controller还有其他地方会调用update接口更新一个或者部分字段。

对于调用方来说，要是能清楚的知道应该修改字段是什么类型，还是比较方便的。特别是在开发阶段，遇到部分字段类型调整的时候，就很容易在编译期都识别出来。