Spring中使用依赖注入替代工厂模式
我目前正在开发一个应用程序，其中将域对象 D 的实例注入到应用程序中。域对象可以按照其 bean 定义的不同组合和排列包含许多类，从而导致许多不同的最终对象 D，我将其称为 D 的不同版本。对于给定版本的 D，我必须填写其中的原始值，然后将其保存到数据库中。使用 JPA 和 Hibernate 将其保存到数据库非常简单。问题在于填充 D 中的值。这些值是使用 SNMP 通过网络获取的，然后填充。对于 D 的每个版本，需要遵循不同的策略，因为 D 的每个版本可能具有不同的 MIB。我目前正在遵循工厂模式。工厂采用 D 的一个版本并返回特定于该 D 版本的 valueRetriever，然后使用该 valueRetriever 来获取值并填充 D。
另一种明显的方法是使用 D 注入配置检索器，然后使用它来检索配置。但我还需要在运行时使用检索器来重新获取配置，因此有必要将检索器也存储在数据库中，从而为每个检索器创建一个新表，这目前看来是一种开销。
我的问题是：是否有更好的方法来检索配置，即在上述场景中使用依赖注入有一个 valueRetriever 。
编辑：AOP在这里有用吗？
I am currently working on an application in which the an instance of the domain object D is injected in to the application. The domain object can contain many classes together in different combinations and permutations as defined by its bean and hence leading to many different final objects D, which I refer to as different versions of D. For a given version of D, I have to fill up the primitive values in it and then save it to the database. Saving it to the database is pretty simple using JPA and Hibernate. The problem is filling up the values in D. The values are fetched over the network using SNMP and then filled up. For each version of D, there is different a strategy to follow, since each version of D may have a different MIB. I are currently following the factory pattern. The factory takes a version of D and returns a valueRetriever for specific to that version of D, which is then used to fetch the values and fill D.
The other obvious way is to inject a configuration retriever in with D and then use it to retrieve the configuration. But I also need to use the retriever during runtime to re-fetch the configurations, so that makes it necessary to store the retriever too in the database, hence creating a new table for each retriever, which seems to an overhead currently.
My question is: Can there be a better way to retrieve the configurations i.e. have a valueRetriever given the above scenario using dependency injection.
Edit: Can AOP be of any use here?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
看来您需要创建的某些对象具有复杂的创建逻辑。您可能不习惯查看 Spring FactoryBean 接口，因为 FactoryBean 可以通过网络获取所有复杂的详细信息，同时允许您创建实例，然后将其注入到其他 bean 中。
It seems that some of the objects you needing to create have a complex creation logic. You may wont to look at the Spring FactoryBean interface, since a FactoryBean can get all the complex details over the network while allowing you to create an instance and then inject it into other beans.
Spring 的 DI 的基础是 Bean Factory/Application Context，因此完全可以替换您正在做的事情。
不同之处在于，您必须能够将所有排列放入 Spring 配置中，并将控制权交给应用程序上下文。如果您做不到这一点，也许您所拥有的解决方案是首选。
更新：我开始担心你的 Spring 解决方案会在可能过于复杂的情况中添加太多不熟悉的技术。
深吸一口气，想想“简单”。
我现在不用担心数据库。如果您可以将所需的所有组合放入 bean 工厂，则 Spring 应用程序上下文将是数据库。我假设这些配置是只读的，一旦声明它们就不会改变。如果情况并非如此，那么一切就都失败了。
The basis for Spring's DI is the Bean Factory/Application Context, so it's entirely possible to replace what you're doing.
The difference will be that you'll have to be able to put all your permutations into the Spring configuration and give control over to the application context. If you can't do that, perhaps the solution you've got is preferred.
UPDATE: I would start to fear that your Spring solution is adding in too many unfamiliar technologies into what might be an overly complicated situation.
Take a breath and think "simple".
I wouldn't worry about the database for now. The Spring application context will be the database if you can get all the combinations you need into the bean factory. I'm assuming these configurations are read-only and not altered once you declare them. If that's not the case all bets are off.