Why does Spring use XML to post components?

Question

I understand the concept of IOC, which we can combine and map different classes through wiring. Each class can get away from the hard code associated with its dependency by delegating posting / relationship processing to the underlying xml (xml context).

Here is my question: why do we use xml? we can simply connect all components using the java class. Instead

<bean id="helloWorld" class="com.vaannila.HelloWorld"> <property name="message" value="HelloWorld"></property> </bean> public static void main(String[] args) { // TODO Auto-generated method stub ApplicationContext context = new ClassPathXmlApplicationContext("beans.xml"); HelloWorld helloWorld = (HelloWorld) context.getBean("helloWorld"); helloWorld.display(); } 

We can rewrite them using

 HelloWorld helloWorld = new HelloWorld(); helloWorld.setMessage("HelloWorld"); helloWorld.display(); 

Answer 1

This is basically the approach that Guice takes, yes.

There are advantages to using XML (or some other similar textual approach). In particular, you can change the wiring of applications without rebuilding anything. If you do not want this, you can do it all manually or use something like Guice.

In addition, Spring exploits the fact that it is all declaratively configured to include features such as AOP. You can do it all manually, but it's a little longer.

Answer 2

Check out the Spring JavaConfig .

Answer 3

Some people have a strange idea that XML is not code, and therefore magically different from code. Sometimes you have to endure people with this idea.

Answer 4

I would say that the reason Spring favors XML over Java is that the two languages ​​are for two different tasks. Java is a programming language. Its purpose is to describe algorithms, programs, control flow, etc. If the output of your program structure requires a complex control flow, Java would be a good choice.

XML is fundamentally different. This is not a programming language. This is a way of describing ordered data, such as a cookbook or vector graphics. If the organization and interdependencies of your software system are static values, then XML may be the right place to host them.

I would say that your configuration files, as a rule, should not be in Java for the same reason that the cookbook should not be in Java. In fact, I could do the same conversion:

 <book> <chapter>It was the best of times, it was the worst of times</chapter> </book> public static void main(String[] args) { String chapter1 = BookXMLParser.loadChapter(1); System.out.println(chapter1); } 

obviously, can also be done entirely in Java:

 public static void main(String[] args) { String chapter1 = "It was the best of times, it was the worst of times"); System.out.println(chapter1); } 

Now, obviously, this is a ridiculous example. Books are hundreds of pages. It would be foolish to keep them in Java code. However, I would make the same argument for the Spring configuration. One of my biggest programs has Spring XML, which has many thousands of lines.

Of course, there is something that can be said in favor of defining this material in Java. In particular, the IDEs could more easily provide additional help about which classes use what other static analysis tools would do a little better analysis of your code for problems.

Then again there are some disadvantages. Giving you this configuration in Java allows the programmer to do all sorts of unpleasant things that are much more difficult to achieve in XML, for example:

 bean1.setName("fred"); if( System.currentTimeMillis() > 1234567890l ) { //Automatically use new feature after next Thursday bean1.setNewFeature(1); } else if( x > 17 ) { switch(y) { case POTATO: bean1.setNewFeature(0); break; case POTAHTO: bean1.setNewFeature(1); case WHO_COULD_ASK_FOR_ANYTHING_MORE_FALLTHROUGH: bean1.setFoo(bar); break; default: baz? bean1.setBar(baz) : if(17 > t) { bean1.setNewFeature(q) } else { throw new RuntimeException("That odd..."); } } } 

Ok, you understand. Your code obviously won't start so badly, but you will be tempted to use some if expression, and then you will use another and then another.

Answer 5

This gives you freedom in the field to be able to change the design or configuration of the application.

eg. on a client site, without access to the compiler (or possibly on a production machine), I can change components around, change database configurations, change logging levels, etc. Alternatively, I can provide configs to those who do not have / t to write code, and they can make (albeit simple) changes to the application (you have to be careful with this, of course).

This is the same argument for all configurations. You can do it all in code. But when is it appropriate?

Answer 6

"I understand the concept of IOC, which allows you to mix and match different classes using wiring."

How can it be that you claim that on the one hand you understand the concept of IoC, and on the next breath offer an example of “hello world” that does not use it? I do not understand.

XML is not 100% required. Even Spring provides the ability to use mostly annotations. Have you changed your mind?

All that Spring can do for you with dynamic proxies as a result of IoC will be difficult to reproduce handwritten code for yourself.

UPDATE: you need to go back and ask Rod Johnson why he chose XML, but it's easy to protect. When he developed the idea for his consulting concerts around 2000-2002, XML was commonly used.

Spring uses XML to externalize the configuration, but you can use annotations if you have Spring 2.5 or higher.

Your question confuses me, because the example you gave that uses Java code is not IoC at all. You do not connect anything when you call it that. I would recommend going back and reading Martin Fowler's IoC article again: http://www.martinfowler.com/articles/injection.html

Answer 7

Posting your beans like this

 HelloWorld helloWorld = new HelloWorld(); helloWorld.setMessage("HelloWorld"); helloWorld.display(); 

It might seem that you have a small amount of beans in your environment.

But what if you have a more complex environment in which you have dozens or hundreds of beans in Spring? My current application has about 205 beans displayed in four different XML files. Posting them in code will be a nightmare.