JavaEE 中无用技术之 JNDI
抛开一大堆技术名词,JNDI 本质是把一些环境变量配置参数放在一起集中维护,或者把可以远程调用的 Java 对象,放在一起集中维护。
其优点是:
a. 分工更专业,可以让一个人管理多个系统的相同的部分,比如数据库连接池配置参数。
b. 其它的优点,没有了。
早期的 EJB 有个“EJB 装配者”的角色,这种实际的工作模式,也许只有 Sun 公司才会有,其它大部分公司都不会有此类角色----大部分公司,都是小型公司,人员分工没有这么细,很多IT系统,连接池参数的调整,是由开发人员完成。
JNDI 也陷入了类似的角色分工问题:很多公司的角色分工与 Sun 公司不一样,Sun 把一个角色分工问题,引入到技术层面,可以想象,问题是很大的。
JNDI 集中维护,带来一个风险,那就是,单点故障风险。
假设我有10个IT系统,都用到 JNDI , 如果运行 JNDI 的服务器瘫痪,那么我这10个IT系统都不能正常工作,影响太大了。稍微有点头脑的人,都会立即想到:分散风险,每个IT系统的服务器,在同一台计算机上运行 JNDI服务。这样问题就来了:还要 JNDI 做什么?
JNDI 刚开始出现的时候,使用 JNDI 有一个特别的目的:有 JNDI 功能支持的 Java EE 服务器,带有连接池。用了 JNDI 就用了连接池。然后,很快 Apache DBCP 和 BoneCP 等独立的数据库连接池组件出现了。如果我用 DBCP ,把数据库连接参数写在环境变量中,数据库连接池参数写在初始化代码处,相比 JNDI 而言,有什么不好么?没有。
结论:JNDI 无用。
---------欢迎大家下载试用我们的 web 单点登录系统, http://zheguisoft.com
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 理解Rust引用及其生命周期标识(上)
· 浏览器原生「磁吸」效果!Anchor Positioning 锚点定位神器解析
· 没有源码,如何修改代码逻辑?
· 一个奇形怪状的面试题:Bean中的CHM要不要加volatile?
· [.NET]调用本地 Deepseek 模型
· Blazor Hybrid适配到HarmonyOS系统
· Obsidian + DeepSeek:免费 AI 助力你的知识管理,让你的笔记飞起来!
· 解决跨域问题的这6种方案,真香!
· 一套基于 Material Design 规范实现的 Blazor 和 Razor 通用组件库
· 分享4款.NET开源、免费、实用的商城系统