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

spring cloud 这玩意这不是银弹，它的很多基础组件其实也仅仅是 [开发出来了] 而已，netflix 的那套其实是有点东西的，可是 netflix 后来直接说我不更新了，2.0 闭源，其实微服务的基础组件是有研发难度的。也是比较有价值的东西，真大路货的话 netflix 也不会突然就说不更新了

同事不是朋友，不要拿对朋友的要求，要求同事。只要干活的时候别人愿意配合，不故意使绊，那同事就是合格的。

@gBurnX
还是那句话送给你：

认为公报私仇是无所谓的管理者，希望你把你的理论推广给你所有的下属知道，并且明言的告诉他们：我不在乎有人在我团队里公报私仇，谁被公报私仇那是活该，谁让它被人抓住机会了呢。呵呵

不再回复，你继续口嗨好了