How would you extract something prior 2.5 version from .xml config? It bothers me because if @Autowired is removed from my arsenal I would not really know what to do.

Say I want to use some DAO implementation.

In service class I usually write:

@Autowired

someDaoInterface generalDao;

Then I typically call

generalDao.someInterfaceMethod(someParam param);

How would I extract implementation from config in Spring 2.0 to use this method?

Is it as dumb as just: new ApplicationContext(pathToXml) and then use .getBean or there is other way?

Why do I ask for taking bean out from configuration file?

Because in Spring MVC how can you perform your logic without getting beans out from the application context.

If you have @Controller handler then you need to make calls to the service classes' methods? So they should be somehow retrieved from the context and the only way so far is using @Autowired? Then I would also want to populate Service classes as I stated in previous example with DAO classes and they also need to be retrieved from the application context, so I would be able to write logic for service classes themself. How would people do it in the past?

I see the @Autowired as the only mean of taking something out, not because it is convenient to wire automatically - I am perfectly ok with XML.

网友答案:

You still have option to wire it explicitely via property or constructor parameter. (Anyway, autowired is not going to work if there is ambiguity in your container )

Of course, you can use application context and getBean() in your java code, but it violates DI pattern and makes all the spring stuff useless. Purpose of DI is to decouple your business loginc from implementation details - it's not business logic it's how and where it dependencies come from. Dependencies are just there.

By using ApplicationContext.getBean() you are breaking this pattern, and introduce dependency to:

spring itself

your configuration names

After you done this, you can as well drop use of DI and spring because you just voided all the advandages DI is providing to you. (BTW, @Autowired also introduces dependency to spring, and violates DI pattern, it also implies that there is only one instance available)

Also, answer is: in ideal case there shall be no reference to spring in your code at all.
No imports, no annotations - just interfaces of collaborating entities.