1. 首先避免或减少 Join 的理由，《高性能 MySQL 》中讲的很清楚了，这个在复杂系统大数据量尤为重要。参考“重构查询方式”章节： https://www.kancloud.cn/ddupl/sql_optimize/1141077
2. 大多数关联场景的 join 是可以拆解成单表查询的，比如 diboot 就是通过注解方式拆解实现关联绑定
3. 少数的跨表字段的搜索查询是没办法避免 join 的，但也可以尽量减少不必要的 join 。比如查询条件有这个字段时再 join 这个表

试一下 [diboot devtools]( https://github.com/dibo-software/diboot-v2) 吧，基础代码可以灵活扩展，生成代码不会覆盖你的自定义代码。

data 用 Object 就行了，直接往里放，返回前端转成 json 都一样。
“用 Object，解析时还得强转”? -- 这里不需要手动转的，交由 spring 统一处理，理论上 JsonResult 应该只用于包装给前端的结果，不需要后端解析。

@exception365 有点理念上的相似，我们目前聚焦在后端数据结构和后端代码上，随 SpringBoot 启动，更易用。

@wangkun025 好吧，看来只能外链到 B 站了

@xuanbg 复制-粘贴香在哪呢，对代码规范性、可维护性、还有程序员自身的成长都没啥好处。复制-粘贴的场景，不如考虑下是否可以封装。

@imkerberos 自动编程还远，不过有不少人在做无代码了。我认为编程离不了程序员，所以是给程序员造工具。

@ivechan 不是，ORM 是基于 Mybatis 和 Mybatis-plus。封装了一个注解实现关联查询绑定的内核，加一个开发助手工具。

@looseChen "嘀 boot" 哈哈

@bk201 目前生成代码只依赖我们的一个基础框架，没有框架生成代码相当于没有做任何封装的代码堆积，企业开发或多或多都有自己的封装的，我们的基础框架已经做到了不错的封装。

@Cbdy @TommyLemon 同意你的观点，完全的自动化要做再往上一层的抽象，接口换成类似 GraphQL 的实现，这个是我们下一步想做的。目前的自动生成和修改静态代码方案是给开发者的工具，让多数企业里的 Java 开发者能够掌控的这个方案。
@TommyLemon APIJSON 也是类似 GraphQL 的实现方案吧，我们可以深入交流一下 ：）

@ldbmcs 感谢反馈，已修复

@zjsxwc 已有项目是不建议使用的，引入两个框架反而增加了复杂度，新的项目可以尝试一下

@acoin cqrs 适合分布式的场景，我们目前版本只是单体应用的解决方案，分布式是下一步的规划

@masker 是有参照 gii，php 开发挺好的代码生成框架，目前的自动化程度比 gii 要高不少了

@AllOfMe 目前版本仅支持 MySQL，其他数据库后续会支持。

@hardman 谢谢，真希望国内有良好的支持开源的环境，可以孵化出像 Apache 这样的开源组织。

@huiyifyj 受益很大，谢谢