不一定.
图方便的话登录之后给返回用户信息没毛病.

但是如果按照接口职责单一原则, 用户信息接口单独获取也无可厚非.

@lujiaxing 再不就是系统里不当使用了 dynamic 类型

@BeautifulSoap 除非你们其中某一个微服务子系统是用弱类型语言开发的 (Javascript), 否则不可能出现 "某一种情况下有这个字段另一种情况下没有这种字段" 的离谱情况. 如果缺字段, 应该是在测试阶段就已经发现了. 毕竟缺字段会导致整个程序跑不通. 我不明白你们公司的业务是怎么搭建的, 怎么测试的, 怎么可能出现其中一个微服务没有按照约定返回字段却顺利通过了的 codereview, ut, 集成测试的.....

@BeautifulSoap 那我就要问问了, 测试干嘛去了. 上线前不做集成测试的么? 怎么可能出现两边接口对不上的问题?

而且如果你要是真对自己团队的成员都如此不信任的话, 那我就只能建议你放弃 json, 改用更加严格的 SOAP 或者 GRPC 了. 那玩意不用校验, 说好的字段缺一个字都会炸.

@BeautifulSoap 对于值类型 (或称原子类型) JSON 字段的 NULL / Undefined 的解析就应该解析为类型默认值. 即: 0.
这是这么多年约定俗成的要求, 也是标准做法. 没什么可争论的. 说了好几遍了 "后端不能信任前端/外部接口传来的数据". 你自己不做数据合法性校验难道还赖前端不给你传么?? 没人说你一定要把 DTO 里改成指针, 你可以不改啊, 但是你代码逻辑肯定要判断啊, 尤其这种支付的场景, 前端本就不该把金额传给你好不好? 标准做法应该是只给你传一个订单号, 以及用户在支付平台扫码得到的 AuthToken... 金额/SKU 摘要/标题等是要你从订单里翻出来的!! 哪儿有前端告诉你是多少钱就是多少钱的道理?

这玩意多得很. 很多医疗系统, 工控系统都是 WinForm 的. 甚至有不少客户用的还是 Windows XP. 你不用 WinForm 准备拿什么玩意给他们用...

不过现在很多都已经转 Avalonia / Uno 了. 毕竟信创嘛, 总要考虑那些统信之类的 Linux 环境的.

@kumoocat 其实这种在 C# 里就很好解决. C# 里对于值类型有 Nullable<T> 包装类, 简化为 "-?", 如: Int32? Color? 等.
如果觉得某个值不应该为 NULL, 要么把对应字段改为 Nullable 类型即可. 这样遇到相应字段不存在/null 的情况下, 反序列化回来的就绝不会是默认值了.

或者更进一步在对应的 Property 上加 [JsonRequired] Attribute. 反序列化发现空值直接报错.

搞什么鬼? JSON 本来就是非严格结构好不好? 经常会有 A 跟 C 对接, A 提供 a, b, c, d 字段但是 C 接受 b, c, e, f 的情况. 毕竟 C 可能还要接 B. 所以遇到 "C 接 A 的时候 e, f 没有值, 接 B 时候 b 没有值" 是极其正常的情况.

如果你觉得这种出现默认值的情况不合理, 要么要求调用方修改, 要么自己在代码里做 Guarding.

要么就不要用 JSON 改用 SOAP XML.

给嘉然打钱

没办法 国家有实名要求. 账号必须是实名的.
不过绑定移动电话号码也确实是大势所趋了. 国外的 app 也要 (例如 Telegram)

@Songxwn @dcsuibian
要不, 你们俩打一架?

@teli 为什么不建议

PowerDesigner 就可以.
你要是觉得 PD 比较古老你可以试试 Navicat. 也有这种功能.

不一定. 有些项目是必须要求先做数据库结构文档的. 例如一些给政府机构做的项目, 当地大数据局事后是可能会要产品的数据结构文档的. CodeFirst 的数据库大概率根本不做这种东西, 数据库结构文档就是实体类. 这种情况下还要现搞数据库结构文档. 所以还不如事先就做好 DBM, 然后从 DBM 直接生产数据库结构和实体类来的方便.