Java 在Spring中使用依赖注入替换工厂模式

我目前正在开发一个应用程序，其中域对象D的实例被注入到应用程序中。域对象可以包含许多类，这些类以其bean定义的不同组合和排列组合在一起，从而导致许多不同的最终对象D，我称之为D的不同版本。对于给定版本的D，我必须填充其中的基本值，然后将其保存到数据库中。使用JPA和Hibernate将其保存到数据库非常简单。问题是填充D中的值。使用SNMP通过网络获取值，然后填充。对于每个版本的D，都有不同的策略要遵循，因为每个版本的D可能有不同的MIB。我目前正在遵循工厂模式。工厂获取D的一个版本，并返回特定于该版本的D的valueRetriever，然后使用它获取值并填充D

另一个明显的方法是将配置检索器与D一起注入，然后使用它检索配置。但我还需要在运行时使用retriever来重新获取配置，因此有必要将retriever也存储在数据库中，从而为每个retriever创建一个新表，这在当前看来是一个开销

我的问题是：有没有更好的方法来检索配置，即在上述场景中使用依赖项注入的valueRetriever

---

编辑：AOP在这里有什么用处吗？

似乎您需要创建的某些对象具有复杂的创建逻辑。您可能不习惯查看SpringFactoryBean接口，因为FactoryBean可以通过网络获得所有复杂的细节，同时允许您创建一个实例，然后将其注入其他Bean

Spring DI的基础是Bean工厂/应用程序上下文，因此完全可以替换您正在做的事情

不同之处在于，您必须能够将所有排列放入Spring配置中，并控制应用程序上下文。如果你不能做到这一点，也许你的解决方案是首选

更新：我开始担心您的Spring解决方案会在可能过于复杂的情况下添加太多不熟悉的技术

深吸一口气，想一想“简单”

---

我现在不会担心数据库。如果您可以将所需的所有组合输入bean工厂，那么Spring应用程序上下文将是数据库。我假设这些配置是只读的，并且在声明后不会更改。如果不是这样的话，所有的赌注都是无效的。

在定义bean的实例化过程中，这可能是正常的，但是在数据库中持久化之后会发生什么呢？存储后，为了在运行时检索值，即从数据库加载D后，基于BeanFactory的工厂是否仍能够提供检索器？如果这不是真的，那么我将不得不以某种方式找到一种方法，将工厂或检索器持久化为D。这将非常类似于将检索器本身注入D，因为将知道要使用什么检索器，但将此检索器持久化为DB是必要的。是的，BeanFactory可能非常有用，因为如果总是从应用程序上下文创建对象，它将连接检索器，而不需要任何额外的代码。但是，当我从数据库加载对象时，这也会起作用吗？这个BeanFactory会为对象提供检索器吗？在这种情况下，spring应用程序上下文将不起作用，因此我必须将一些实体与域对象本身一起存储在DB中。从数据库（持久存储）加载它们与从spring配置初始化它们有什么不同？你一直坚持这是必要的，但我还是不明白为什么。请用“我是这么说的”或“我就是这么做的”以外的话来解释。我想读一个有说服力的解释。我实际上是在要求对Bean工厂进行澄清。我的意思是，当我使用entityManager.load（id）时，如何调用BeanFactory，而不是使用加载后拦截器。BeanFactory是在第一次实例化期间定义此对象的bean中定义的。在这种情况下，它是如何发挥作用的？我没有用过BeanFactory，所以我可能错过了很多天真的观点。请容忍我。