JNDI 作为服务定位器设计模式不好吗？答案

【问题标题】：Is JNDI bad as service locator design pattern?JNDI 作为服务定位器设计模式不好吗？
【发布时间】：2016-04-06 05:00:12
【问题描述】：

我是一名 Java EE nooby 开发人员，根据互联网上的许多资源声称服务定位器设计模式是一种反模式，因为它隐藏了类依赖和更多东西，应该尽可能避免使用 Dependecy而是注入，我们知道 JNDI 是服务定位器模式的实现。

我用谷歌搜索检查 JNDI 是服务定位器的实现，我发现这个响应声称这个：Understanding JNDI

虽然我看到 JNDI 在 Java EE 应用程序中用于多种用途（数据源、EJB 查找...），那么我应该使用它还是应该尽可能避免它？如果 JNDI 还不错的话服务定位器不是吗？

【问题讨论】：

不知道为什么投反对票，确定问题不“正确”但“问题”本身并不“坏”。值得问问他们是否感到困惑。
@mawalker 值得一问的是，软件中是否存在一些普遍认可的“邪恶”含义（没有，因为在这种情况下使用它是一个类别错误），以及是否存在服务定位器模式展示它的一些广泛同意的原因，我从未听说过。否则，OP只是在没有解释的情况下随意使用单词并询问他是否正确。
@mawalker 谢谢你的评论，我也是，我不明白为什么，尤其是没有评论来清除它，我不是来这里得分也不是投票:)
您的措辞有点夸张，但一般问题保持不变。（我对 JNDI 不太了解，无法对问题本身发表评论）但编辑掉问题的“邪恶”部分，并尝试更详细地解释为什么您认为它是反模式等可能是使用。
这不是答案，而是评论。仅仅声称有很多这样的资源而不引用其中任何一个是不够的，我不明白为什么 SO 应该成为任意 Internet 垃圾的验证站点。

标签： java jakarta-ee design-patterns jndi service-locator

【解决方案1】：

我认为您的问题的一部分，服务定位器是否好或 JNDI 是否与这种模式有关，这有点深奥。作为一名多年的软件架构师，我可以在这里给出一个一般性建议，模式本身不好也不坏，它只是一个解决方案，之前在许多情况下成功使用过，因此被宣布为模式以便用于将来类似的情况。另一件事是，与许多年前相反，当一个人必须背诵 GoF 书才能在面试中幸存下来时，如今理解 Java EE 等框架的底层概念比实现所有框架更重要这些模式，因为您必须实现的东西通常非常简单明了，但是使用依赖于这些概念。

关于您问题的第二部分，您几乎不需要直接使用 JNDI，而是使用建立在它之上的概念，如注入 - 这就是您应该在应用程序中使用的内容。

【讨论】：

当然，我们一直不需要使用 JNDI 进行查找，但我发现很多消息来源说服务定位器是一种反模式，原因有很多，无论如何感谢您的时间.

【解决方案2】：

恕我直言，这是一个可怕的模式，因为它是一个巨大的安全漏洞。如果在编译时就知道依赖关系并且不会改变，那么审计、门控和控制可能的漏洞就会容易得多。即使在一个组织内，JDNI 也是一个等待被恶意使用的特洛伊木马，如果一个不良行为者可能危及其他区域和您的网络，那么通过一个实施不佳/不知情的应用程序获取任何他们想要的负载。这个 log4j 崩溃证明了这一点：不要让应用程序在任何时候查找和加载任何内容。这是一个愚蠢的想法。不安全。

【讨论】：

【解决方案3】：

在业务环境中，我们最终需要跨应用程序使用不同类型的数据，因此将它们存储在共享位置是有意义的。例如，您可能有一组共享同一组用户的应用程序，我们需要每个应用程序的授权信息，列出他们拥有的角色，以便我们知道他们需要访问什么。这种东西进入 LDAP 数据存储，您可以将其视为针对快速读取访问而优化的分层数据库。

各种各样的东西都可以放在这些数据存储中，例如，应用服务器在其中存储连接池是很正常的。其中很多，例如用户、角色和连接池，都是您完成工作所需的重要内容。

JNDI 是用于访问这些 LDAP 数据存储的标准 Java API。

关于服务定位器设计模式的讨厌的事情是，执行查找的客户端代码必须对它正在查询的东西（主要是从哪里获取）了解太多，并且将查找硬编码在客户端使代码不灵活且难以测试。但是，如果我们使用依赖注入（无论是 CDI、Spring 还是其他），我们可以让框架将我们想要的值注入到代码中，而 JNDI 查找是在框架代码中而不是在应用程序中处理的。这意味着您可以使用 JNDI，而您的应用程序代码不必使用服务定位器模式。

【讨论】：