CODEWITHSUNDEEP
javaspring
Edmond
Edmond

Reputation: 644

When to use Spring to manage/instantiate a bean

For example if I have a ContainingClass and DependencyClass(and its interface):

public class ContainingClass {
    IDependencyClass d;
    public ContainingClass(IDependencyClass d){
        this.d = d;
    }
}

They are decoupled enough. At this time, obviously we can use the constructor to wire them up. Why bother to define them in the spring context?

Can you guys talk about what's the advantage to use spring container to manage beans? Thank you in advance.

In addition: If we use spring container too much, I think it would be rather difficult to maintain the container and refactor the code. Isn't it?

Upvotes: 1

Views: 398

Answers (2)

ced-b
ced-b

Reputation: 4065

Here are three points to consider:

  1. Does it make sense to use Spring in the first place? For a massive Java Web Application with may classes and packages - Yes (assuming you considered any possible alternatives). If it's just a couple of lines Java App - probably, no.

  2. Consistency. If the rest of the project is Spring to the core and configured as beans in XML, then you would probably stick to that. How is anything else being done? Are you starting from scratch and are using Spring MVC? Then stick to that pattern, you can see plenty of examples in the Spring documentation.

  3. How decoupled are your two classes. For example if your ContainingClass is a service on the service layer and your IDependencyClass is a DAO on the data access layer, most likely, I would keep them configured separately and let Spring do the injection. Especially, when I am planning on using the IDependencyClass in another context or making it so it can be switched without ContainingClass ever noticing (for example in case the underlying access layer changes).

Also, consider using annotation based configuration, that cuts down the need for separate XML files dramatically, and makes it (if done right) easier to trace through the code as having to switch between XML and Java code.

Upvotes: 0

Paul Sanwald
Paul Sanwald

Reputation: 11329

The container is usually used as a top level entity responsible for instantiating all your objects. It solves the problem you eventually have to solve in that something has to new all your objects together and bring your application to life.

Before dependency injection frameworks, people solved this problem by having separate Factory classes that were responsible for wiring together objects. In larger applications, this resulted in a lot of needless boilerplate classes that were doing nothing but calling "new" on a set of objects. Spring allowed you to essentially remove that concern from your application.

For very small applications, you probably don't feel the burn of having to construct your application, and using a spring container is probably overkill. But for larger applications, using a container like spring cuts down on boilerplate cut, and makes it easier to wire together pieces of your application for testing purposes, without wiring together the full application context every time.

Additionally, dependency injection containers encourage a certain coding style which leads to a more testable system in general, namely, injecting dependencies rather than newing them in a constructor. This allows you to easily substitute mock objects for things like database connections.

For your specific question, the answer is that there must exist some other class in your application that knows how to instantiate both ContainingClass, as well as where to find an instance of IDependencyClass. Spring can do this for you, or you must write a class that does it yourself.

Upvotes: 1

Related Questions