Using Dependency Injection in Spring to replace Factory pattern

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?

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.

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.