JNDI 作为服务定位器设计模式不好吗?
Posted
技术标签:
【中文标题】JNDI 作为服务定位器设计模式不好吗?【英文标题】:Is JNDI bad as service locator design pattern? 【发布时间】: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 垃圾的验证站点。 【参考方案1】:我认为您的问题的一部分,服务定位器是否好或 JNDI 是否与这种模式有关,这有点深奥。作为一名多年的软件架构师,我可以在这里给出一个一般性建议,模式本身不好也不坏,它只是一个解决方案,之前在许多情况下成功使用过,因此被宣布为模式以便用于将来类似的情况。另一件事是,与许多年前相反,当一个人必须背诵 GoF 书才能在面试中幸存下来时,如今理解 Java EE 等框架的底层概念比实现所有框架更重要这些模式,因为您必须实现的东西通常非常简单明了,但是使用依赖于这些概念。
关于您问题的第二部分,您几乎不需要直接使用 JNDI,而是使用建立在它之上的概念,如注入 - 这就是您应该在应用程序中使用的内容。
【讨论】:
当然,我们一直不需要使用 JNDI 进行查找,但我发现很多消息来源说服务定位器是一种反模式,原因有很多,无论如何感谢您的时间.【参考方案2】:恕我直言,这是一个可怕的模式,因为它是一个巨大的安全漏洞。如果在编译时就知道依赖关系并且不会改变,那么审计、门控和控制可能的漏洞就会容易得多。即使在一个组织内,JDNI 也是一个等待被恶意使用的特洛伊木马,如果一个不良行为者可能危及其他区域和您的网络,那么通过一个实施不佳/不知情的应用程序获取任何他们想要的负载。这个 log4j 崩溃证明了这一点:不要让应用程序在任何时候查找和加载任何内容。这是一个愚蠢的想法。不安全。
【讨论】:
【参考方案3】:在业务环境中,我们最终需要跨应用程序使用不同类型的数据,因此将它们存储在共享位置是有意义的。例如,您可能有一组共享同一组用户的应用程序,我们需要每个应用程序的授权信息,列出他们拥有的角色,以便我们知道他们需要访问什么。这种东西进入 LDAP 数据存储,您可以将其视为针对快速读取访问而优化的分层数据库。
各种各样的东西都可以放在这些数据存储中,例如,应用服务器在其中存储连接池是很正常的。其中很多,例如用户、角色和连接池,都是您完成工作所需的重要内容。
JNDI 是用于访问这些 LDAP 数据存储的标准 Java API。
关于服务定位器设计模式的讨厌的事情是,执行查找的客户端代码必须对它正在查询的东西(主要是从哪里获取)了解太多,并且将查找硬编码在客户端使代码不灵活且难以测试。但是,如果我们使用依赖注入(无论是 CDI、Spring 还是其他),我们可以让框架将我们想要的值注入到代码中,而 JNDI 查找是在框架代码中而不是在应用程序中处理的。这意味着您可以使用 JNDI,而您的应用程序代码不必使用服务定位器模式。
【讨论】:
以上是关于JNDI 作为服务定位器设计模式不好吗?的主要内容,如果未能解决你的问题,请参考以下文章