【问题标题】:Should I create many singletons or singleton context with references to my state and objects?我应该使用对我的状态和对象的引用创建许多单例或单例上下文吗?
【发布时间】:2014-11-28 16:54:04
【问题描述】:

我在一个项目中使用 Guice。由于这是第一次,我想知道如何保持和传递状态,即包含一些用户输入的对象或其他地方需要的长寿命对象(不是第一次注入的地方)。

例如,我的应用程序有一个用户可以启动和停止的服务器。此外,用户可以输入一些数据,这些数据会导致需要保存在内存中的状态。

目前我看到了两种可能性:

  1. 有一个Context 类,其范围为@Singleton 以及对其他类的一些引用,这些类可以保持我的状态并为我提供某些功能。 Context 类可以让我访问Server 实例、用户数据、其他服务等。 Context 的实例可能由 Guice 注入。 因此,如果我想停止我的服务器,我需要 Context 作为依赖项(而不是服务器)。

这有点违背 Guice 网站上的建议(注入直接依赖项,而不是使用链式 getter 访问“真实”依赖项)。

  1. @Singleton 注释所有应该只存在一次并被注入到其他几个类中的类。因此,我将只有一个单例服务器,在某个地方有一个包含用户数据的类,等等。

单例模式 (GoF) 被认为是糟糕的设计。因此,我想知道是否应该尽量减少 @Singleton 的使用,或者这是否是使用 Guice 分别依赖注入的不同故事。

还有其他可能性或更好的方法吗?

【问题讨论】:

  • 单例模式 (GoF) 与单例范围不同。反对单例模式的论点通常不适用于单例范围。

标签: java architecture singleton guice


【解决方案1】:

我认为您的大部分问题都与依赖注入范式有关。首先,使用 DI 并不意味着每个托管 bean 都应该是 Singleton。托管 bean 有自己的生命周期。它们可以在每次访问/请求/会话或单例时实例化。

您应该关心的另一件事是使用 DI,我们通常会连接我们的主要应用程序设计。您应该考虑您的域对象及其关系,而不是 DI(Guice/Spring)。

例如,在您的情况下,如果您需要一个 bean 中的服务对象,那么您就有这两个类之间的关系,而无需与 Context 有关系!

如果所有用户都可以看到不同用户插入的数据,那么请在您的应用程序中设置服务单例。如果每个用户的 Server bean 的状态不同,那么将 bean Session 的范围设置为允许每个用户拥有自己的 Server bean。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-05-04
    • 2013-10-29
    • 1970-01-01
    • 1970-01-01
    • 2021-12-08
    • 1970-01-01
    • 2011-04-12
    相关资源
    最近更新 更多