Web 应用程序上下文和服务上下文之间的双向依赖关系答案

【问题标题】：bidirectional dependency between web applicaton context and service contextWeb 应用程序上下文和服务上下文之间的双向依赖关系
【发布时间】：2012-07-25 16:50:44
【问题描述】：

我有 2 个 spring 上下文：“webapplication”上下文和“core”上下文。上下文“核心”在服务器启动时初始化，并附加到保存上下文的 Singleton 类。 “webapplication”上下文在 webapplication 启动时被初始化。

我想将 bean 依赖项从一个上下文中的 bean 注入到另一个上下文中（双向访问）。 Web 应用程序 bean 将是“会话”范围的 bean。

我正在测试这个概念证明：webapp bean -->（取决于）核心 bean -->（取决于另一个）webapp bean。

在 web 应用程序上下文初始化时，我可以将“核心”bean 注入“webapplication”bean（一个访问单例的 BeanFactory 会产生魔力），但不知道如何做相反的事情；因为保存 WebApplicationContext 的 Spring ThreadLocal 尚未初始化。

问题是。这是我试图做的可能吗？如果答案是“是”，你会怎么做？

提前致谢。

编辑：

我意识到我做错了什么。事实是我试图在错误的时间向服务层注入对会话 bean 的依赖；也就是说，在我没有当前用户会话的网络初始化时。

【问题讨论】：

标签： java spring jakarta-ee

【解决方案1】：

在我看来，这像是一个架构问题，而不是技术问题（当然也不是 Spring）问题。 core 上下文和 web 上下文之间的分离非常好。前者处理业务流程，后者负责表示，可能是一些 API。

web（表示、访问）对 core 的依赖是可以理解和必需的——毕竟您是在业务例程之上构建接口。这就是 spring-mvc 默认的工作方式，为核心上下文创建单独的子 (Web) 应用程序上下文。

我很难想象反向依赖的用例。为什么你的业务逻辑依赖于 web 层？如果您尝试将应用程序迁移到不同的表示技术（桌面、移动）怎么办？你能证明这种反向依赖的原因吗？ 会话 bean 是什么意思？

双向依赖，以及持有类加载器广泛引用应用程序上下文的静态单例应该表明设计有问题。

【讨论】：

我的业务逻辑依赖于会话数据，因为在向后端层发送一些信息之前，我需要（示例）从服务 bean 内部访问/处理购物车 bean（具有会话范围）。单例模式是许多架构中的常见做法，我们的单例持有 ApplicationContext（而不是类加载器）。为什么你说这是一种糟糕的设计实践？
@andresoviedo：感谢您的澄清。你的业务逻辑不是从 web 层调用的吗？如果是这种情况，只需在 Web 层读取购物车并将其作为参数显式传递。关于单例 - 在单例的静态字段中保留对 ApplicationContext 的引用（单例具有类加载器范围，这就是我的意思）只是丑陋的，而 Spring 为此提供了更好的机制，例如上下文继承（如在 Spring MVC 中提到的）。更不用说单例本身有时被称为反模式。
谢谢。小米业务逻辑是从 web 层调用的。我已经考虑将 web bean 作为参数传递给服务层，但我想使用作用域会话 bean 的注入来简化组件的布线。