What is the problem with not using Spring

Question

I am trying to understand Spring. I have read about it and done some tutorials. I kind of get the IoC paradigm and the fact that DI is its implementation in Spring.

My question is this: What do you lose by not using Spring? I understand this is a big question and somewhat subjective. But if you could write a few dot points or give an example of a problem that could occur if Spring was not used, I think that would help me and many other people.

Answer 1

There are no problems actually. But if you start writing your code you will end up with a homegrown framework much like Spring. The thing you get with using Spring is that the framework is already more generic (than your own) and you can use it in a lot of different projects. And the most important (maybe) is that Spring is well tested with so many users using it.

Of course you can try also another framework not just Spring. There are a lots out there...

Answer 2

A glib answer is that you'd have to code it all yourself. I don't know much about Spring (yet), but even the basic act of constructor injection would require a lot of code whereas with Spring you need two edit points:

In config:

  <sectionGroup name="spring">
    <section name="context" type="Spring.Context.Support.ContextHandler, Spring.Core"/>
    <section name="objects" type="Spring.Context.Support.DefaultSectionHandler, Spring.Core" />
  </sectionGroup>

  <spring>
    <context>
      <resource uri="config://spring/objects"/>
    </context>
    <objects xmlns="http://www.springframework.net"&gt;
      <object name="mediaLibrary" type="AlbumLibraryWPF.AlbumLibrary, AlbumLibrary"/>
    </objects>
  </spring>

In code:

  IApplicationContext ctx = ContextRegistry.GetContext();
  library = (Library)ctx.GetObject("mediaLibrary");

Which would you rather do: write a DI framework yourself or concentrate of building your solution?

Answer 3

Spring is far more than just another IoC tool (think of DAO related stuffs, convenient MVC support, testing tools, ...). In my opinion, it has gradually grown to a kind of "flavor" of Java. But that's not the point :) Speaking of IoC/DI, what you loose not using it is the easiest way to gain loose coupling in your application, that is associated to reusability. Obviously, most of people tend to think of reusability of a component in another project, which, in my experience, occurs not that often. Greatest benefit of reusability appears when you have to unittest your code. Programming through interface and using DI/IoC make unittests so easy that even those who are reluctant to unit test will start loving it.

Loose coupling and benefit in matter of UT is one thing you'll lose.

Answer 4

IoC is mostly a good thing within the Java language because when most applications start growing and you don't design for modularization/loose coupling, you end up with a big pile of interconnected classes without no sensible boundaries.

For starters, Spring and other IoC/DI frameworks makes you think about modularization right from the start. This is big because if you have your code well modularized/loose coupled, you end up componentizing and reusing much more wich leads to better unit testing (if you do unit testing anyway).

If I want to write a DAO, I can define its interface up front:

interface IPersonDao {
  List<Person> getPersonsByTeam(String teamName);
}

then, I can just call for the implementation of this interface from anywhere in the src where's Spring is being "applied". Suppose i need it in a service layer:

class MyService {
  @Autowired
  IPersonDao svc;
}

or in a test class:

class TestPersonDao {
  @Autowired
  IPersonDao svc;

   @Test
  void testGetPersons(){
    List<Person> persons = svc.getPersonsByTeam("billing");
    Assert.assertDataSet(persons, "billing.xml");
  }
}

Besides, my Dao implementation can hide the complexities of data access without messing with the Dao contract. If I require a hibernate session or a persistence manager, I just declare that:

class JpaPersonDao implements IPersonDao {

@PersistenceContext
EntityManager em;

  List<Person> getPersonsByTeam(String tm) {
    em.createQuery("...");
  }
}

Componentization of classes requires a registry in order to wire collaborating beans. This could be developed by hand, but there are already DI frameworks that do this. Besides, Spring has alot of other stuff like exception translation, support for aspect programming, mvc frameworks, portlet frameworks, integration with hibernate, jpa and/or other db stacks which of course integrate nicely with the Spring IoC stuff.

Answer 5

Spring is much more than a DI framework. There a lot of areas that it will make programming easier for you:

• JDBC, Hibernate, JMS templates (dramatically reduce code line count)
• Aspect programming
• Security (Spring security)
• Spring MVC
• Spring Web Services

These are just some examples - there are many more. You don't have to use any of the above, but there all part of a mature, well designed framework and in general they make things easier.

The core of Spring is of course Dependency Injection. The benefits of using a DI framework may not be apparent for small projects, but there are more than evident for large and complicated ones. Martin Fowler explains Inversion of Control very clearly. Of course there other alternatives (Guice for example), but I would say that Spring is now an industry standard.

Answer 6

I did a write-up on why people use dependency injection frameworks (like Spring and Google Guice). Most tutorials neglect this, but IMHO it is the most important thing.

If you understand the problem you have, and what problems all these patterns/frameworks solve, only then are you able to make good software and great architectural choices.

Read about it here: http://www.redcode.nl/blog/2010/01/dependency-injection-dissection

Answer 7

Put simply, you apply dependency injection to write clean and testable code. Also in return you achieve a design in which the caller knows which implementation to use(inject) rather than callee (this is what's famous as the "Hollywood principle"). Now if you don't use use DI frameworks like Spring and Guice you try to achieve dependency injection using factories. But factories come with a cost of boilerplate code and uneasy clean-up while testing. Some people also find other strengths in these frameworks which is their easy integration with frameworks belonging to different tiers like Struts, Hibernate etcetera.