About Future DTO Features

[pot-mot]

Jimmer DTO 作为一个能够极大提高开发效率的功能，我们用户总会对此有着更多的功能需求。
考虑到 Jimmer 现阶段的开发者确实没有足够精力去维护一个复杂度更高的 DTO 语言及生态，希望这个帖子可以集中一下那些没有急切到 Feature Request 的设想，通过讨论整合出一些实现成本低、合理且需求广泛的 DTO 设计。

[pot-mot]

Output DTO 像 Fetcher 一样的复用

这是我个人的一个较为急切但实现成本极高的需求，对大多数场景不那么适用，所以放缓，预期可以在未来一年或更后面实现。

问题在于我个人的 Jimmer 模型设计器在后端对形状的操作极多，但无法较好的实现类型抽象，例如：

• package 实体在很多 dto 中都需要实现向父级递归以获取全路径。
• enum 实体在几乎所有场景下都需要携带 enumItems 且形状完全一致，但不得不在 DTO 中重复好多次。
• table 实体下挂 column ，column 又下挂 association 等等这样的用于生成其他代码的超级聚合根类型，内部的子类型与简单 View 形状相同。

实现难点：跨文件 DTO 编译、属性类型解析

目前的 work around：将子类型在需要时 toEntity 在转换成固定的入口 View 类型，然后将大部分操作作为这个入口 View 类型的扩展，风险主要在于 unload （这点和 NPE 一致）

以及个人简单的想法，就是 DTO 还是应该作为 Fetcher 的一种更高级别的实现，所以确实还是由衷希望 output DTO 可以做到 Fetcher 级别的复用

[TokgoRonin]

DTO语言希望添加一个关键字，例如 immutable，让生成的dto为jimmer的不可变对象。
原因：java的pojo无法区分前端参数没有传而导致的null，以及参数传了但是传的值为null。这在java历史中一直是无法区分的，导致API在设计上很混乱。在添加了这个关键字之后，可以区分这两种情况，在后端API开发中更加规范。