关于 Java 和 Spring boot 开发体验的一些疑惑，请高手解答

之前写前端比较多，最近开始用 Spring boot 开发 api
使用的是 JPA Hibernate orm+jdk21 方案，我不知道为什么感觉国内很多人不喜欢这个 Hibernate ，但是我自己用下来感觉非常好，它最牛逼的是可以按照 Entity 生成数据库结构，非常智能，所以你只要把实体定义好，一切都 ok 了，很容易维护。
有个插件 JPA buddy ，非常好用，可以很好规范代码。
JPA 也可以自定义 sql ，很灵活，除了在转成 json 的时候，会遇到无限循环的问题，其他感觉都很好。
感觉 Spring boot 写后端，除了 JAVA 本身有点啰嗦，还有编译很浪费时间，其他都还蛮不错的。

但是 JPA 通过 Entity 生成数据库的时候，为什么字段顺序和 Entity 是不一样的，是打乱的，，id 的位置会随机出现~~我槽，这就像要喝汤的时候飞进了一个苍蝇，我看网上有很多人说要 hack 一下，官方无解，但这个太离谱了。

然后就是 CommandLineRunner ，我本来的需求是需要给项目 seed 一点初始化数据，这个 CommandLineRunner 只在启动的时候自动执行，不能通过 cli 命令执行，，泥马这个 CommandLineRunner 和 Command 一点关系都没有啊，我内个去，所以 seed 数据只能在 CommandLineRunner 加 if 条件。你去看人家 PHP laravel 都有 artisan cil 工具啊，这个可是天天都要用的，为啥你没有啊~~~你 Tomcat 都可以监听指令，为啥就不做一个监听 命令行指令的。
后来我看了一个 spring boot cli 的插件，结果完全不是这个概念。。

为什么这么成熟的框架连这些基本都做不好啊~~谁可以告诉我一下~~

然后我现在在看 liquidbase 和 flyway ，还是 flyway 吧，直接 sql 多优雅，liquidbase 那个语法不能忍受~~

谁能告诉我怎么才能优雅的搞后端呢？

1.只有很多单表操作我才会倾向于 JPA 。复杂联表查询、CTE 子查询，sql 长的要命那种一般都在数据库客户端上调试写好了，直接搬到 mybatis xml 中。

2.生产没有使用过 entity 去操作表结构，因为 DDL 操作都要提单过 DBA 操作。

3.CommandLineRunner 接口定义就是应用启动后去执行自定义逻辑，此操作生命周期内只有一次。想自己调用，留个接口随便玩。

4.没听过不知道

5.哪有什么优雅不优雅，以前我喜欢复杂的设计模式，现在我只想一把梭完了回家

见过几十张表连接或者复杂 sql 一两百行，就知道这些人是用不了 jpa 的，性能能劣化到没法使用

个人浅见：spring data jpa 和 mybatis 本质上是两种建模方式，一个从数据库表到 Java 对象，一个从 Java 对象到数据库表，换一种说法就是一个是面向对象，一个是面向集合，关系数据库本身是集合理论，而用 SQL 实现继承，多态，多重继承很复杂，很多人会用 SQL 实现同样的功能，但是他不知道在 Java 中的对应关系，还有我个人觉得 Hibernate 很复杂，就像很多人说的，写着写着自己就写不下去了，还是觉得 mybatis 写的舒服，简单说就是驾驭不了。

国内不喜欢的是 HQL ，并非 Hibernate 本身，JPA 单表根据签名自动合成查询还是很好用的。HQL 最大的问题是，当你写出来的时候，脑子里还是人肉要翻译成 SQL ，然后才能判断这个语句是否高效，那么 HQL 解决了什么问题？并没有，还不如直接写 SQL 简单可控。

再说 ORM ，一旦涉及到一对多甚至多对多的关系，那就不得不提 cache 和 lazy load 了，还有 1+n 查询，这些事情是自己做，还是交给 ORM 去做，仁者见仁，使用 ORM 就得很熟悉其工作机制，否则很容易写出损害性能的操作来。使用 ORM 提高的开发效率，也比较有限，偶尔由于不精通，踩到个坑，恐怕省下来的时间全都还回去。

最后说 JPA ，80%以上的需求都可以由 JPA 实现，少数情况写个 SQL 也就搞定了。

给运行中的程序发送管理指令，为什么不用 JMX 呢？如果只是每次都启动的命令行，你定义一个 bean ，然后 main 中根据参数决定初始化哪个 bean 不就好了？

直接上 querydsl 配合 jpa ，比 mybatis 好用，flyway 最新版免费版只支持最新版数据库，不支持低一版本数据库，liquibase 可以配合 JPA buddy 直接生成文件，方便很多。
开发的时候初始数据我觉得可以用单元测试，因为单元测试可以回滚事物和 mock ，而且还能提高代码健壮性

建议使用 JDBC 手写，和 Servlet 来写 Web 项目。

Doma2

根据不同的条件拼接 sql 的时候 JPA 就难搞了.

楼上说的基本正确：
1-主要是企业项目不可能依附于某个人，肯定是有其他人接力维护
2-用 jpa 的好处是可以省很多代码，坏处就是实力不行的家伙用这玩意搞多表关联偷懒，或者大佬开辟的 jpa 基石后续维护很容易维护成狗屎,其他狗屎尚且还有评鉴的余地，jpa 一旦出现 BUG 就是很难定位，那后人就得不断品尝的这坨越来越大的狗屎。
3-而且企业开发代码目前版本要求是：
      1-代码简单易读(保证人员调度可接力)
      2-程序稳定易维护(禁止不打招呼炫技，用特殊算法请和项目其他成员解释，必须署名在内网留一篇可复现核实的技术文档)，并且要开一次技术分享会来讲讲你这玩意解决了啥。这招出来后很多炫技刷 kpi 的就老实很多了,因为他得抽工作时间或者私人时间准备技术分享会了
      3-降低架构设计成本(老板也是人精，越来越觉得这点业务也犯得着用上那么多架构技术？)