- 主题:好奇问一下
那是没用上Entity Bean和Stateful session Bean这两个贵物……
【 在 chzhang7901 的大作中提到: 】
: EJB需要啥维护啊，就是Java程序，只是调用方式是EJB的。
: 我上家公司，10年前用的是EJB，2020年前转成微服务了。
: EJB就是开发接口用的。后面的逻辑没EJB什么事。
: ...................
--
FROM 222.70.21.*
哈哈哈
自己控制的transaction。用不上这些。
【 在 oldwatch 的大作中提到: 】
: 那是没用上Entity Bean和Stateful session Bean这两个贵物……
:
--
FROM 120.244.234.*
全家桶的威力还是很爽的。
尝试过某国外大厂用的轻量框架，没事改点东西就得把框架源代码翻出来看，精力有限真的没精力去写那么多定制化功能，同时覆盖各种犄角旮旯了场景。spring基本配置配置就能上了。
【 在 hgoldfish 的大作中提到: 】
: java 转 go 还不如把现有的 java 体系整整。java spring 全家桶太恶心了，不知道为啥大家还都在用。不用 spring，java 是一个非常“轻快”的后端语言。
:
--
FROM 119.130.229.*
这个有点想当然了，新人哪有话语权做技术选型，顶多就是参与讨论，老人们其实不在乎折腾的，反正干活的不是自己，再说即便从客观角度很多新的框架（其实也没那么新了，spring都多少年了）也确实比老古董好用得多。
当然也不排除有些小项目新人自己就定了，不过这种出了坑也得自己填，哪天技术委员会强制迁移到统一技术栈，苦的还是自己。
【 在 oldwatch 的大作中提到: 】
: 面向KPI选型
: 换你是新人你也会建议开一个新赛道把老人拉平到同一起跑线
:
--
FROM 221.224.15.*
也就互联网吧？我感觉nodejs更适合做轻量级的业务后台。复杂逻辑反正都是sql实现。
【 在 mopo 的大作中提到: 】
: 如果不是遗留系统，从来没见过有项目用，技术选型的时候根本都不会纳入候选，近几年java本身的业务后台地位也是有点岌岌可危，我知道的好多都要求转go了
--
FROM 101.80.249.*
啥单位复杂逻辑sql实现?
【 在 Xjt 的大作中提到: 】
: 也就互联网吧？我感觉nodejs更适合做轻量级的业务后台。复杂逻辑反正都是sql实现。
--
FROM 60.253.150.*
多了，比如复杂条件的搜索，你不靠数据库索引？
【 在 licy 的大作中提到: 】
: 啥单位复杂逻辑sql实现?
:
:
--
FROM 101.80.249.*
nodejs一般是所谓的全栈喜欢用的前后端一把梭方案，正经做后端的不会去趟这个坑，hello world和线上千锤百炼的系统还是有一定代际差的，当然也不排除nodejs后来居上的潜力，只是得先解决js/ts系诸多流派的问题
【 在 Xjt 的大作中提到: 】
: 也就互联网吧？我感觉nodejs更适合做轻量级的业务后台。复杂逻辑反正都是sql实现。
--
FROM 180.107.105.*
用索引，和复杂查询走sql是两码事，互联网企业确实不太待见复杂的sql语句，尤其是在线系统，sql逻辑越简单越好，离线的话很多只是类sql语句，为了做分布式也不支持特别复杂的语法
【 在 Xjt 的大作中提到: 】
: 多了，比如复杂条件的搜索，你不靠数据库索引？
: :
--
FROM 180.107.105.*
并不是，前端这年代都是小程序，和nodejs毫无关系
另外后端的一切逻辑无非增删改查，实在看不出有什么普通互联网服务的后端java能做nodejs做不了的。
【 在 mopo 的大作中提到: 】
: nodejs一般是所谓的全栈喜欢用的前后端一把梭方案，正经做后端的不会去趟这个坑，hello world和线上千锤百炼的系统还是有一定代际差的，当然也不排除nodejs后来居上的潜力，只是得先解决js/ts系诸多流派的问题
:
--
FROM 101.80.249.*