@alamaya
问题是你到底是怎么考虑代码复用的？

哦，看到一段操作数据库的代码，就不能放在 Controller 里？就得写个 service 装起来，搞不好这个 service 还得先是一个接口，然后做出一个 Impl 实现类来？是这个意思吗？

考虑复用难道不是先考虑一下有没有复用的可能性吗？当根本就没有复用的可能性时，就像我前面说的，业务代码几轮拆分后都是高内聚的，哪有让你复用的机会？也要“复用”吗？

如果你一开始就已经想到了这段代码在业务上就是需要复用的，甚至这个需求就在眼前，那我万分支持你把立刻把这段代码抽出来变成一个 service，给人复用。如果你一开始根本想不出来要在哪里复用，那为什么要复用？这不是过度设计又是什么呢？就像很多项目写一堆直到项目死掉都不会改成实现的接口，美其名曰 [规范] 。。。

退一万步讲，你到了遇到有需要复用的那一天，再把 Controller 里的代码抽出来变成一个复用的 service，这很费事吗？

我见了太多的人，都是嘴上空谈说 [复用] ，我直接问他们关于眼前项目，你觉得这个位置的代码在哪里可能会复用？鲜有答上来的，他们大部分也估不到项目在发展中会遇到什么。只不过是看别人是这么干的，或者说按所谓的规范应该这么干的。。。

除非你已经想到需要的地方，那么再动手，不要过早动手，优先完成业务。这是我的法则。就目前的实践经验看，和我配合的人都挺喜欢的，没觉得我的代码就是屎山。当然有人不认同我能理解，毕竟张口闭口设计规范的人非常之多，谢欢在项目里写一堆到死也不会发生变化的接口的人更不少

@ebony0319 ORM 的方向如果是对的，它就不会遇到复杂场景必须回到 SQL 这种尴尬的问题。本质是对象模型并不能如当初的人们估算的那样取代关系模型，只要关系模型自身不倒，ORM 就始终处于尴尬的位置

@hutoer 为什么要在初期就考虑代码复用？为啥不能遇到能复用的时候，再去把代码抽成 service ？为啥一定在初期搞这种过度设计？

@ipwx Java 的线程模型是 1 比 1 换成内核线程的模型。这个东西在经典时代是足够的，但是在现在就未必了，其实 Java 一直在折腾新的携程模型。

另外，我的本意是，部署一个 Java 项目(线程)，哪怕是比较小的项目，拖着一个巨大的虚拟机和基本函数库，也造成其启动内存占用偏大，和启动速度太慢

@ipwx 我认同 Jit 可能更快，但是我不认同你关于内存的说法，资源总是不够用的，特别是当你进程数量起来以后，一个进程能减掉一半的内存，就是一大笔成本，Java 这个语言确实在云原生时代遇到了挑战，就是其虚拟机太过庞大，否则 oracle 就不会去折腾 graavlm

@ColinZeb 用过，linq 很好用，但是还是那句话，复杂查询最后你还是会回到 SQL 上来的


@yema50 没啥怪的，看你选严谨还是选灵活，我自己的项目就经常在 Controller 层加业务

@Kipp
@BBCCBB
我明确的反对这个想法，QueryWrapper 本质就是 ActiveRecord，把它直接放在最靠近业务的地方才是对的，硬要封装起来啦就又变成了 JPA 的思路，那还不如用 JPA 。

你要追求灵活性，你就要失去一些结构上的严谨，以及代码感觉看上去像事务脚本

你要追求严谨性，你的代码就要封装套层，失去灵活性。

我选择灵活性，ActiveRecord 的诞生就是为了灵活而不是为了严谨性，要严谨的面向对象的话，选 JPA

@yema50
方式 1 就是传统的 mybatis 方法，你要用方式 1，没必要用 mybatis-plus

方式 2 本身就是脱胎于 ActiveRecord 的链式调用，这个方式最初的来源就是我上面说的 Ruby on Rails,它提供了高度的灵活性，代价的就是代码看上去像事务脚本，但是我认为这个在开发效率，这是值得的。

最后，后端的项目，在经历过几轮微服务拆分后，业务是高度内聚的，你几乎很难遇到多处复用你这个查询代码的情况，我认为初期就考虑复用，这个想法是有问题的

没有，Java 拖着一个虚拟机就不可能轻量，数据量小建议直接搞个脚本语言开搞，重型框架只有数据量足够大的时候才有价值

@encro 阿里云的 RDS 比很多人自建的快，楼上这些说性能的能把自己硬件软件配置报一下吗？楼主最好也把配置报一下，我见过有些人不懂，直接自己在云 ECS 上建 MySQL 的，他那个 ECS 还不是高性能 IO 的，那不就这个性能。要知道很多 Mysql 看起来测试性能很高，那人家那硬件动不动就是在 64 核，123G 内存，SSD 阵列，参数还优化到极致。不比你自己用 MySQL 社区版默认装的强到哪里去了

@yema50 单表查询请一律不要自己定义 mapper 和 service，直接用表反向映射生成实体，mapper，service，然后你构建 QueryWrapper 注入查询条件，用 mapper 还是用 service 就随你了。

这类工具的设计目的就是为了解决纯 SQL 工具在单表查询时不如 ORM 方便的。如果你单表查询还要去自己定义 mapper 和 service，那等于这个工具没有起作用

@thet
@wellsc
有一说一，C#和 net core 比起 Java 这种有历史包袱的语言内存占用是少了很多，但是比起 Go 这种直接编译出本地 AOT，压根就没有虚拟机拖累的语言，那就不够看了。net core 据说也在折腾编译成目标平台代码，不带虚拟机，就看啥时候能弄成了

这本质是两种思想的碰撞，JPA 的思维是 ORM，mybatis 则来自“sqlUtils”(sql 帮助工具)。

在关系数据库群雄争霸的那个时代，SQL 标准没有统一，在编程界的当时有一个迫切的需求：如果我半途要换关系数据库怎么办？不像现在这个 MySQL“称霸世界”(并没有)的时代，当时做到一半换数据库是真的常见的需求。而当时 SQL 作为一种 4GL 语言其实思想并没有广泛的被人接受，当时的业界还是面向对象的天下。于是就有人说：为什么不能用面向对象来映射关系数据库的表呢？这就是 ORM(Object Relational Mapping,对象关系映射)最初的思想来源。也是最主要的两个 ORM 库，Hibernate 和.Net Entity Framework 的指导思想。

时间飞速前进，新世纪后发生了两个非常主要的变化：

第 1 个变化是，关系数据库面对海量的互联网数据开始变的力不从心，为了解决海量数据的问题（当时大数据还没有像现在这么发达），不得不妥协，把单库拆分成多库，这么一拆之后，关系数据库之前以强约束，关联关系计算为卖点的特性，不再是优势(拆分之后的库无法使用这些特性，只能搞什么最终一致，Base 理论之类的聊以自慰)，这也是为啥 MySQL 这种在经典关系数据库理论看上去简直就是个残废的关系数据库大行其道的原因。同时，因为经典关系数据库的特性不再重要，关系数据库开始沦为数据仓库，选哪家的数据库就变的不再重要了，更换数据库变成了伪需求，不再存在，ORM 理论的重要来源：屏蔽各个关系数据库之间的不同点，以让用户更换数据库无忧，这一最初的重要需求，不再存在。


第 2 个变化是，进入新世纪后，SQL 作为一个 4GL 语言的价值终于被发现，大家纷纷表示这种“do not tell me how to do,tell me what you want(不要告诉我怎么干，告诉我你要什么)”的模式真是太香了；而且一众 NoSQL 的鼓吹者们高举大旗准备驱逐关系数据库，结果闹了很久后发现自己拿 SQL 居然毫无办法，只能捏着鼻子，纷纷又开始在自己的查询器上加上了 SQL 支持。传统关系数据库是没落了，但是 SQL 以及背后承载的关系运算的思维，在新时代反而是大行其道。复杂查询直接上 SQL 那感觉是真香，连新普的大数据从业者都自嘲自己说：后端是 CRUD Boy，我们就是 SQL Boy 。


总之，新世纪的竞争里，目前看是 SQL 赢了，ORM 的思维只比较适合无连表的 CRUD，对单表或多个单表执行 OLTP 业务，此时的 ORM 是比你写多个 insert，select 啥的方便的，但是一旦涉及到复杂的联表，group，having 查询，大家否纷纷直接上 SQL 更方便。

另外从业界的进化你也可以看得出来，纯正的 ORM，在 Hibernate 和.Net Entity Framework 之后几乎就没有再看到出名的了，JPA 则是从 Hibernate 发展来的，可以看做延续和强化，但本质不会变。但是各种"SQL 工具类"型的查询库，还在层出不穷的出，而且这些工具并非墨守成规，Ruby on Rails 开历史先河，吸收 ORM 对单表查询很友好这个优势，发展出了 Active Record 这种即可以从单表结构直接映射出对象，并可以在查询的时候以链式调用的方式注入查询条件；同时，都保留了能够方便自定义 SQL 的能力。其它 Sql 工具一看纷纷跟进，包括现在 Mybatis 的几个强化工具都是这个思路。

所以我觉得接下来一段比较长的时间，除非出现新的变革，占优势的应该还是各种更亲和 Sql，但是同时具备表映射对象能力的各种 SQL 帮助工具。

js 有啥难度？直接堆代码就行，发现不对再去搜特性就好。前端的天坑是 CSS 好吧，这玩意，真前端都没几个真的搞的很明白的

这分明是 bug

一点都不担心，早在人月神话时代，那时市面上一会就会冒出一款全新的语言或者“开发框架”，各个都宣称自己可以“降低成本”，“再也不用聘请昂贵的程序员了”。

所以，软件开发也最高的成本就是人力成本，资本想替代掉这昂贵的人力成本不是第一天的事情。用不着觉得不开心，想着降低成本是资本的本能。

现实的核心问题，不在于低代码无代码能否取代程序员。而在于本身的复杂度是来源于业务自身的，开发程序的难度确实是在下降，而且还会继续下降，2000 年的时候你搭个网站简直是黑科技，现在谁不会搭网站？但是 2000 年复杂的 ERP 业务，到现在仍然复杂。

程序开发本质是服务业，所以更多的时候，不要把眼光盯死在程序本身。程序说到底，只是个电脑工具，和 Office,photoshop，没有区别。盯紧业务更重要

云桌面这东西最大的问题是价格太贵，而且以目前的技术发展看，根本没有可能降下来。

多嘴问一句，你们都是从哪里翻到 gitbook 的，google 了一下没有找到途径

@myCupOfTea 行呗，老板这不已经发话了，既然老板都不怕死，你怕什么，照着他说的弄。反正手上随时准备后路，老板要死就让他死好了。