@joesonw
@des
请教，如何解决数据访问权问题，授权和鉴权往往只能解决角色(你是谁)和一般性授权问题（你能访问这个接口吗），但是实际业务中，往往要解决“你访问的数据是属于你的吗”这个问题，这个问题严格说也是鉴权，但是是业务强相关的。业务强相关的东西，网关做不了

去尝试写一下 CSS 和 JS 。如果你自我感觉 CSS 写的比 JS 还溜，甚至能轻松的修改别人的 CSS 。你就更适合前端，反之就是后端。

CSS 是测试前端的试金石，甚至可以说，现在大部分正在从事前端工作的人，在 CSS 这块都是不合格的。证据就是他们写出来的 CSS 没法让别人改，别人写的 CSS 他们也搞不明白，解决别人写的 CSS 的布局问题的方式是拿自己熟悉的方式自己重写。。。虽然 CSS 自从加入了 flex 后，以及现在 web 开发多是在开发 App UI 而不是复杂排版页，导致对 CSS 的要求大大降低了。CSS 仍然是测试前端的试金石，因为这东西代表着另外一个领域；和普通的顺序式编程思路完全不同

工程化的思维是近 10 年才引入前端的，后端则早的多了，至少人月神话那个时候就开始了。前端的构建工具不够好用的根源还是时间太短，坑没踩完。不说别的就光一个 npm 设计问题，连作者都觉得设计失败的玩意还是很多人说 npm 设计的好。。。再过个 10 年，等社区对什么是真正的好，达成共识了，估计前端工程化就成熟了，现在内部意见都不统一，你觉得好的东西我觉得是屎，这种环境下工具链不可能让人满意

需要性能的岗位，看能否取代 C++。目前还是处于早期试用阶段，所以你比较难发现一些大型案例

分布式关系数据库目前还处于技术完善期，其实后端业务说来说去，除了某些对算法要求极高的领域，基本都是卡在数据库这一块了，数据库作为后端存储状态的关键点，在海量数据的这个时代是一个 [薄弱点] ，一旦这个点被攻破，可认为后端编程就是无脑的

电车目前从技术上仍然处于完善期，但是油车现在几乎在所有的地方都限上牌。汽车目前处于技术换代时期，最好的建议就是不要买。等等党永不会输

快到不惑而没有 200w 存款的人一大把，楼主是不是在凡尔赛？

@charlie21 我已经非常明确的描述了我的观点，我并不抵触严谨代码结构。我只是强调应该根据不同的的情况选择不同的方式，我非常开心能够不用和你这种永远停留在自己的舒适区的人一起共事，之前也遇到过这样，号称“不按他的规范来就开除”，然后我就看着他有一天就撞到了他的规范无法处理，然后必须妥协的时候，最后此人的选择就是一走了之。。。

在 Controller 里写数据库处理逻辑非常常见，很早就有技术文章描述过这种“事务脚本编程”方式的优劣，如果你看过别的语言的 mvc 框架，也能看到这样的实现，只是你自己不可接受而已，随便你怎么想，我来这里不是和人吵架的，而是和人交流，我不排斥任何处理方式，只要他能更好的解决问题就行。

@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 拖着一个虚拟机就不可能轻量，数据量小建议直接搞个脚本语言开搞，重型框架只有数据量足够大的时候才有价值