搜索
  • SpringBoot+mybatis的JAVA开发框架是不是很落后？
  • 发布于 2个月前
  • 364 热度
    13 评论

看到别人说推荐一个 java 架构，默默想了下好像在公司里面看到的大多数都是 springBoot+mybatis 的形式，DDD 推出后好像也没看到什么公司用，是只有大公司在用吗？那现在国内外比较新的 java 架构都有啥呢？

说明一下:
1. 这里提到架构只是感觉好像接触到的都是属于 MVC 、分层、微服务一类的，DDD 感觉算设计，也算架构的一种吧。（不对勿喷）
2. 框架上的话，确实好用能提效就行，主要使用的 ORM 框架也是 mybatis 加一些增强框架（ mybatis-plus\fluent-mybatis\或者用 mybatis 的 provider 自己写了一个简单的增强）。对于 orm 真的都是简单的直接用，复杂写 SQL ，所以 mybatis 用的倒还习惯
3. 技术选型上基本都是以 Spring 为主，都是跟着一路用 mvc ，webflux 什么的，都是换框架。这些框架的底子思想，都是出现很久了。
所以主要问题：都是个人观点，欢迎讨论
1. 架构。每个语言其实都差。不多，该分分，该拆拆，做通信，做协调什么的。都谈不上落后吧？
2. 框架。主要以 mybatis 为主的我，就想看看大佬们的意见

用户评论
  • 半生輕狂客
  • 编程领域最基本的数据结构和算法，都是几十年没变过的东西了。年龄比你爹还大，我就问你老不老？你只需要把这些老得不能再老的东西学明白，写代码就能做到随心所欲。想写 Java 写 Java ，想写 Go 就写 Go 。当你真的学会了编程而不是编程语言、框架、三方库，什么新鲜工具你还能玩不转？
  • 2025/1/10 9:17:00 [ 0 ] [ 0 ] 回复
  • 山有木兮
  • 数据库访问一般就是两个门派：
    - JPA 、Hibernate 等 ORM：这类就是解决大部分 CRUD 需求的，简单的查询，涉及到多表，复杂查询就会性能低下，上手门槛也更高
    - JDBC Temple 、MyBatis 、JOOQ 这类 SQL Helper：这类就是解决复杂查询的，因为本来就是 SQL ，想咋写就咋写。因为本来就是 SQL ，因此先说说第二类的发展历程，一开始大家写 JDBC 还好，写多了发现模板代码太多了，主要是两个层面，一个是连接这边的代码，一个是 ResultSet 做数据转换的代码，所以诞生了类似于 Apache Commons DbUtils 这种工具来简化，在 Spring 环境中则是 Spring JdbcTemplate 。

    接下来事情就会朝着两极发展，还是先从 SQL 说起
    Commons DbUtils 、JdbcTemplate 这类框架只简化了连接和响应映射，在动态 SQL 的支持比较少，因此诞生了 MyBatis 也就是 JdbcTemplate 高级版，通过模板引擎解决动态 SQL ，并且支持预定义的一些 SQL

    当然 Mybatis 被人诟病的 XML ，还有动态能力在复杂场景还是有限的，例如写一个递归形式的动态条件（再举个例子，DAO 方法只穿入一个 filter ，这个 filter 可以是普通的 KeyValue 过滤，也可以多个 KV 组成的 AnyOf 和 AllOf 多重过滤，后两者对应的就是 id in (select id from t where f1 and/or f2 and/or f3...)，这里面还可以动态拼接，我认为这种在 Java 里要用多态和类型匹配去做，MyBatis 对这个支持就不太行）

    讲完了问题，就引出解决 MyBatis 这个陈旧框架的升级版 JOOQ ，这里用 TypeSafe 的 API 来编写复杂 SQL ，一来不需要频繁和 SQL 直接交互（ Mybatis 也有一些这种痛点），也能避免出错；二来动态能力增强了，我能在 Java 代码而不是 XML 了编写内容。到这里就是 SQL 帮助类这一方向发展的极端了（如果有更好的框架，可以提出），这里没有提到其他帖子的注入 MyBatis Plus (Join ），tk mybatis 等增强，而是因为他们要做的事情和 JPA 类似。

    接下来谈谈 JPA ，JPA 的诞生我认为是解决 Commons DbUtils 、JdbcTemplate 这类框架中，对于一个表应该有的大部分普通操作 CRUD 没有预定义好一些模板代码，导致用户又需要频繁去写 findById ，findAll ，findCountByXXX 等操作（如果直接用 MyBatis ，也有这个问题，因此没有一个方案是一劳永逸的），简单来说我认为 JPA 就是用面向对象的方式编写简单查询，然后无感生成对应的模板 SQL 。但是这里的问题在于，JPA 这种注解时，方法名编写查询的方式，注定写不了复杂 SQL ，这又是一个新的问题。

    总结，合并，从整个历程来看，数据库访问技术里，最终是趋向两个方向：简单查询自动生成、复杂 SQL 查询代码动态化，一个是前期需求，一个是后期需求。

    以 MyBatis 和 JPA 举例，这两个框架都诞生了融合二者的三方框架：
    - MyBatis Plus/ Mybatis Plus Join/ tk.mybatis
    - JPA Criteria API, JPA QueryDSL

    JPA/Hibernate 不能替代 SQL 。您应该充分利用 JPA 和 SQL ，并将它们组合成一个成功的解决方案。
    MyBatis + 自动生成类增强插件似乎可行，但 MyBatis 自身的 SQL 能力不够强力，加上生成框架大部分就是国人写的，我并不是说国人的技术能力不行，而是国内这个职场氛围和文化，诞生不出来好的框架，原因有很多：996 、35 毕业、生存压力（投放广告），相对于 QueryDSL 、JOOQ 而言，国内的插件生态，文档不完善，功能不丰富。。。
  • 2025/1/10 9:14:00 [ 0 ] [ 0 ] 回复
  • 远山迷雾
  • DDD 还是香的。但是它确实门槛高，需要开发能够理解业务，整个团队需要形成统一语言。这在一些公司确实难做到。

    MyBatis 倒是接触过一点遗留项目里的，真的是太恶心了，XML 里面写 SQL ，SQL 里面嵌套 XML 写逻辑。。。反正我是不理解。我觉得还不如 JPA 。
    当然我也不是夸 JPA ，JPA 在项目刚开始的时候还算香，但是遇到性能问题、连表查询就头痛了。
    用 JDBC 手搓 SQL 也不是不行，现在 IDEA 的提示已经可以避免掉 SQL 里出现 typo 的问题了。
    不过我还是最喜欢 JOOQ ，真的香。像 querydsl 一样的 type safe sql ，并且还不是 JPA ，不会让你写不出想要的 SQL 。当然也有缺点，就是不好写单元测试。不过前面几个好像也不行 🤣。有条件的话可以用 testcontainers 起一个 docker 来跑集成测试，跑不了 docker 的话也可以考虑用一个 embedded DB 。

    但是我觉得 SQL 这部分最恶心的还不是这些框架的限制，而是有的人会写出几十上百行 SQL （不管国内国外）。这种代码根本没有维护的欲望。DDD 里的聚合根其实可以一定程度上规避这种问题，限定数据库查询的范围，需要范围之外的数据就用别的 SQL 单独去查询一下。
  • 2025/1/10 9:10:00 [ 0 ] [ 0 ] 回复
  • 城南诗客
  • 公司一堆瞎搬硬套所谓 DDD 的真是够无语的，看着挺高大上的其实做的一塌糊涂，bug,多有牛毛，哪那么多场景需要你用全套的 DDD 啊，本来就不是啥多先进的东西，不过是工程需要罢了，搞什么技术崇拜啊。
  • 2025/1/10 9:07:00 [ 0 ] [ 0 ] 回复
  • 太伤人
  • 有一说一，国外？国外现在流行 next.js 一把梭。做起来再改语言，能不能活还打个问号呢。先不谈是不是牛马，这没法聊下去了。国内的整体研发体系的效率就是比海外高，为什么高？人家在那吭哧吭哧先设计再写代码，单元测试啥都一个不漏。国内？呵呵，又不是不能用，先跑起来，线上调试就是一个热更新的事。整个对比我觉得不是在一个概念上的对比，完全没有什么意义。结论就是，谈技术研发架构，就不要拿国内和国外对比。
  • 2025/1/10 8:54:00 [ 0 ] [ 0 ] 回复
  • 梦清幽
  • 你以为就国内卷，国外不卷？不卷的话，这些新东西怎么出来的？新东西，它可不仅仅是技术进步，更多的是经济利益，个人的，公司的，巴拉巴拉，国外那帮人，为了技术一直牵引全球（收割韭菜），当然就不停的发明各种新技术，新概念，增加复杂度等等。
    另外就是实际应用场景的区分，国外很多场景他就遇不到，比如人员数量的差异，国内很多场景下人员数量是国外的几倍，然后一些架构复杂性，比如国内特有的一些，xxx 领导主管 xxx ，负责 xx 业务，在 xxx 场景下他要排第一，在 xxx 场景下他要排第二等等，我不知道国外讲不讲这种办公室政治，反正国内这种，类似的 oa 系统，做出来超级复杂，不是技术负责，是业务难度复杂，导致不得不写出很复杂的 sql ，或者很复杂的数据表，这种情况下，mybatis 可能是比较适合的，那干啥要换呢？
  • 2025/1/10 8:42:00 [ 0 ] [ 0 ] 回复
  • 花落微凉
  • 个人观点，对开发来说，国内都是业务驱动，能承载业务，降低开发、学习成本的工具就是好工具，谁还不是个 crud boy 。
    对老板来说，国内的开发就是 java 体系主流，java boy 一抓一大把，用人成本低廉，换个齿轮的成本极低，根本没理由推动新技术落地，你换个小众一点的技术体系，招个人焦头烂额水平还参差不齐，招到差的产出的质量说不定把新技术的优势都抵消了，老板肯定是不愿意的。
    你说大佬？开发轮子的大佬根本不需要考虑这个问题，自然有能力推动最佳实践，良禽择木而栖。
  • 2025/1/10 8:36:00 [ 0 ] [ 0 ] 回复
  • 长青诗
  • 国内 Java 技术栈普遍在 2015 年左右，但不是都那么陈旧，也有好多公司开始用 quarkus/vert.x ，用 JPA 和 JOOQ 甚至 JdbcTemplate 的其实也不少，反正我主导的项目里没出现过 mybatis 相关的东西。
  • 2025/1/10 8:31:00 [ 0 ] [ 0 ] 回复
可能感兴趣的话题