DTO语言引入了新的复杂性

[Wszl]

inputDTO确实在实际开发中是比较麻烦的一件事情，参数少了不愿意怕麻烦不定义，参数多了就不得不定义。
看了下相关文档以及视频，发现还是需要新定义dto文件，而且是需要编写非java文件来生成。这个步骤就更麻烦了。
即使是抛开第一次使用dto的配置，学习等成本来说。
inputDTO的本质本质就是一些查询参数，简单查询接口不讨论，复杂查询接口的DTO在用SpringMVC或者其他框架的情况下，也就是个简单的pojo。配合lombok等一些工具可以做到很简单。
曾经刚毕业的时候遇到一些不规范的写法，inputDTO全部用Map来代替，虽然看起来很丑陋，重构也麻烦，但就在定义这个角度来说，他是很简单的。
希望在解决inputDTO这块能有更好的实现

[babyfish-ct]

不是查询参数，是复杂表单。

查询参数是specification DTO(你看的那个视频没讲)，请参见视频合集“Jimmer基础三板斧”中的的“Jimmer之任意复杂动态查询”（复杂查询比你现在所想的强大得多，使用DSL超级简单，使用Specification DTO更简单）

[babyfish-ct]

Output/Input DTO一定是复杂数据结构，并且希望和实体数据结构（深度和广度）彼此转化，从而实现将复杂结果POJO作为一个整体进行一次性查询和一次性修改的能力。如果不是与此有关的复杂功能，参数随便用什么都可以，也犯不着发明DTO语言。

DTO语言是在支持上百名用户的过程中逐步演化出来来的，为了解决此类复杂问题，技术方案变了很多次，经过了长达半年的讨论，最后稳定下来，最终解决此类复杂问题最简单的方案。

你现在讨论的这个场景和DTO语言要解决的场景没有任何一丁点关系，所以，不明白为什么会如此