问题
Ok, this question is gonna get a lot of downvotes...
I just saw this question where a guy is facing some issue with spring xml beanfactory thing.
I would like to understand why this:
<bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean">
<property name="namingStrategy">
<ref bean="namingStrategy"/>
</property>
<property name="mappingResources">
<list>
<!--<value>genericdaotest/domain/Person.hbm.xml</value>-->
</list>
</property>
<property name="hibernateProperties">
<props>
<prop key="hibernate.dialect">org.hibernate.dialect.HSQLDialect</prop>
<prop key="hibernate.show_sql">true</prop>
<prop key="hibernate.hbm2ddl.auto">create</prop>
</props>
</property>
<property name="dataSource">
<ref bean="dataSource"/>
</property>
</bean>
should be anyhow better than this:
public class BeanFactory {
public LocalSessionFactoryBean getSessionFactory() {
LocalSessionFactoryBean bean = new LocalSessionFactoryBean();
bean.setNamingStrategy(getNamingStrategy());
bean.setMappingResources(Arrays.asList(getPerson());
bean.setHibernateProperties(new Properties() {{
setProperty("hibernate.dialect", "org.hibernate.dialect.HSQLDialect");
setProperty("hibernate.show_sql", "true")
setProperty("hibernate.hbm2ddl.auto", "create");
}});
bean.setDataSource(getDataSource());
return bean;
}
}
It's shorter, it's easier to understand, it doesn't have Spring quirks, it doesn't require an external library to run (that may clash with others), it's step-by-step debuggable, it' unit testable, it doesn't need reflection, it potentially benefits of OOP, it's easier to refactor from your IDE, it's type checked at compile time, it's Java -not xml- and doesn't require to be parsed at runtime, when it compiles you know already that it is formally correct (and not discovering exceptions at runtime), and if you need to externalize some configuration parameter you use a properties file (that will contain real configuration).
And more than everything: I don't need a huge singleton class called "BeanFactory" in my code who's responsibility is to instantiate every kind of objects (like a huge and ugly service locator that has nothing to do with IoC principles).
So, the question is:
why should I prefer creating a huge XML over creating my objects composing and aggregating them in Java?
回答1:
Using a relatively modern version of Spring you are not forced to use xml at all. Simply annotate your class as follows...
@Configuration
public class BeanFactory {
@Bean
public LocalSessionFactoryBean sessionFactory() {
LocalSessionFactoryBean bean = new LocalSessionFactoryBean();
bean.setNamingStrategy(getNamingStrategy());
bean.setMappingResources(Arrays.asList(getPerson());
bean.setHibernateProperties(new Properties() {{
setProperty("hibernate.dialect", "org.hibernate.dialect.HSQLDialect");
setProperty("hibernate.show_sql", "true")
setProperty("hibernate.hbm2ddl.auto", "create");
}});
bean.setDataSource(dataSource());
return bean;
}
@Bean
public DataSource dataSource() {
....
}
The real benefit of dependency injection is in the classes that use your beans. Your code isn't cluttered with plumbing code, it is focused on solving the business problem.
回答2:
A better question might be "What are the advantages of dependency injection?" After all, there are other dependency injection frameworks out there that use pure java instead of XML. (see Google Guice)
It all comes down to finding useful techniques to decouple your code and then 'wire' it together somewhere else.
回答3:
why should I prefer creating a huge XML over creating my objects composing and aggregating them in Java?
My understanding on the answers I received, is that many people consider XML not being source code but configuration. Hence, modifying XML is considered less risky or more convenient than changing a Java class.
A benefit of modifying the XML over modifying Java source is that you don't need to recompile your application; so those changes can be pushed easier in test/production without being involved in normal development activity (and testing). And this - in my personal view - is the worst part of the story.
I got answer on what are the good things on IoC, which is not what I asked. My intent is/was to understand why so many developers prefer having such XML files instead of relying on Java source to program the construction of objects.
Fortunately I see that this approach is on the way to be dismissed (or at least reduced), in favor of Spring annotations and/or other frameworks which are based on Java source code (like Guice that has been mentioned).
回答4:
Inversion of control or dependency injection will help you to control your dependency without touching your source codes. And you could do this in a XML
回答5:
The IOC xml instantiation provides modularity to your application. By using autowiring, you do not have to explicitly set the member variables/services within a class. Think of it this way many classes using 1..2..3..n services, may need several constructors or a factory class, or the worst approach getting and setting the services used by that class. By using Spring you can define that with in a class, and consumer of that class doesn't need to know or call a special method. You could define that bean component with an annotated notation and now just autowire it where necessary, no need to code factories.
As far as XML driven, I think hyness said it best, autowiring via annotations can greatly reduce the burden of maintaining an xml document, if you can upgrade your version of Spring.
回答6:
Despite the fact that using XML files to configure your app could add more complexity by increasing the number of files you have to cater for. They do give you the advantage of keeping the code intact and avoiding changes for cases where you might wanna use a different Hibernate Dialect for instance and so on.
来源：https://stackoverflow.com/questions/14219799/whats-the-benefit-of-spring-xml-ioc-over-java-instantiation