CODEWITHSUNDEEP
javaspringdependency-injectioninversion-of-control
Akimbo
Akimbo

Reputation: 61

What is the point of XML IoC in Java Spring if dependency injection can be done without it?

I have been trying to wrap my head around IoC and dependency injection. I think I am starting to understand the benefit of dependency injection in large apps. If I'm correct in understanding, dependency injection is beneficial when you have consistent interfaces, as you'll be able to only change an implementation without having to change your whole app.

What I don't understand is where XML comes into all of this (And I know there are other IoC methods like annotations now, but unless the answer is "XML sucks and you should use annotations", let's not go there yet).

What is the difference between managing this: 

public class MyApp {

    public static void main(String[] args) {

        ItemFinder theQuarterFinder = new QuarterItemFinder();
        FortuneService theFortune = new HappyFortuneService(theQuarterFinder);
        Coach theCoach = new WrestlingCoach(theFortune);

        System.out.println(theCoach.getDailyWorkout());
        System.out.println(theCoach.getDailyFortune());
        System.out.println(theCoach.getItem());


    }

}

And managing this with an xml: 

public class HelloSpringApp {

    public static void main(String[] args) {

        //Load spring configuration file
        ClassPathXmlApplicationContext context = 
                new ClassPathXmlApplicationContext("applicationContext.xml");

        //Retrieve bean from spring container

        Coach theCoach = context.getBean("myCoach", Coach.class);

        System.out.println(theCoach.getDailyWorkout());
        System.out.println(theCoach.getDailyFortune());
        System.out.println(theCoach.getItem());

        context.close();
    }

}

    <bean id="myItemFinder" class="com.luv2code.springdemo.QuarterItemFinder">
    </bean>

    <bean id="myFortune"
        class="com.luv2code.springdemo.HappyFortuneService">
        <constructor-arg ref="myItemFinder" />
    </bean>

    <bean id="myCoach" class="com.luv2code.springdemo.WrestlingCoach">
        <constructor-arg ref="myFortune" />
    </bean>

If I were to change the itemFinder implementation, I would be changing exactly the same amount of code, only doing it in an XML file vs the main app function. Is that really preferable? Trying to track down refs in XML seems worse to deal with than just changing one of the "new" calls in MyApp.

If I'm understanding correctly, both examples do dependency injection. One just moves the logic out of app and into an XML file. and creates Spring Beans. But we are kinda making beans even without an XML context, correct?

Upvotes: 1

Views: 255

Answers (1)

Steven
Steven

Reputation: 172835

Here's an excerpt from section 12.2.1 of Dependency Injection Principles, Practices, and Patterns which explains the advantages and disadvantages of using (XML) configuration files.

12.2.1 Configuring containers with configuration files

When DI Containers first appeared back in the early 2000s, they all used XML as a configuration mechanism — most things did back then. Experience with XML as a configuration mechanism later revealed that this is rarely the best option.

XML tends to be verbose and brittle. When you configure a DI Container in XML, you identify various classes and interfaces, but you have no compiler support to warn you if you misspell something. Even if the class names are correct, there’s no guarantee that the required assembly is going to be in the application’s probing path.

To add insult to injury, the expressiveness of XML is limited compared to that of plain code. This sometimes makes it hard or impossible to express certain configurations in a configuration file that are otherwise trivial to express in code [...]

The advantage of configuration files, on the other hand, is that you can change the behavior of the application without recompilation. This is valuable if you develop software that ships to thousands of customers, because it gives them a way to customize the application. But if you write an internal application or a website where you control the deployment environment, it’s often easier to recompile and redeploy the application when you need to change the behavior.

To summarize: (XML) configuration files are (only) valuable in late-binding scenarios, where the types are unknown at compile-time, which most likely happens when allowing an application to be extended using plug-ins.

Upvotes: 2

Related Questions