DI without a framework without, like, framework, generate, factory

amy

Hi,
I want to deploy an application heavily relies on DI, but dont want to set up the entire DI framework like Spring. I use a pretty simple method, to write all the dependency in a factory class, and get them by name when use.

It is just hard code the relationship into a BeanFactory, are there any existed projects can read out the spring configuration file and generate such a BeanFactory with all the dependencies in it? So I can use it without to install a framework and the XML configuration file.

Thanks!

Regards,
Sam Huang

I'm not quite sure what you are trying to do here.  Is there any chance you can explain a little more?

I use Spring Framework to manage the dependency during development, but when deployed to server side, it needs to do a lot of configuration in order to make it run. Instead, I build a factory to generate the beans in server, to simulate the function as Spring Framework.

// the interface I get my dependencies from
public interface MyBeanFactory {
public Object getBean(String name) throws Exception;
}

// in server, i use this one to get object, they are hard coded
public class SimpleBeanFactory implements MyBeanFactory {
public Object getBean(String name) throws Exception{
if(name.equalsIgnoreCase(quot;helloquot;){return new Hello();}
else ...
}

//in development, I use Spring to manage the dependency,
public class SpringBeanFactory extends XmlBeanFactory implements MyBeanFactory {
}

I have the SimpleBeanFactory in server and use SpringBeanFactory in local to make use the XML configuration.

My question is there any tool for generating SimpleBeanFactory here from the XML configuration so I dont need to deploy a framework to the server, instead I can use just a factory class  to obtain all the dependencies?

Thx!


Originally Posted by samhuangMy question is there any tool for generating SimpleBeanFactory here from the XML configuration so I dont need to deploy a framework to the server, instead I can use just a factory class  to obtain all the dependencies?

None that I know of.  I'm not sure why you would even want to do this.  Surely if you can use Spring in the development environment it would make sense to run with this?

It requires some process when you add a new 3rd party package or framework to the server side, so I wonder to add a bean factory as part of the code should be much more eaiser.


Originally Posted by samhuangIt requires some process when you add a new 3rd party package or framework to the server side, so I wonder to add a bean factory as part of the code should be much more eaiser.

I'm sorry I don't understand what you are getting at.  You are using Spring to wire everything together, but when you deploy it you want to replicate what Spring does yourself.  I don't see how this is easier.

I think I understand the issue.  For whatever reasons, policy or resistence to Spring itself, one cannot just add Spring to an existing system.   

I did this once.  I could not add Spring to a project, so I just created a property file that had the  bean assignments, and a simple factory read it and exposed the beans via the getBean method.   This is very common thing to do.  What I did not do is try to reuse the Spring XML config file, and of course, did not try to duplicate full DI.  I would not recommend having both Spring and a substitute in same project, would be a maintenance headache in future and besides will prevent taking advantage of advanced Spring features like AOP.


Originally Posted by jbetancourtI think I understand the issue.  For whatever reasons, policy or resistence to Spring itself, one cannot just add Spring to an existing system.

I'm with you on this one, I understand the polictical problems as I've been there myself.  What I don't understand is why you'd use it in development and then not in deployment.  I would have thought it makes more sense to go with a general approach.Originally Posted by jbetancourtI would not recommend having both Spring and a substitute in same project, would be a maintenance headache in future and besides will prevent taking advantage of advanced Spring features like AOP.

Indeed.