What does the Spring framework do? Should I use it? Why or why not?

  • So, I'm starting a brand-new project in Java, and am considering using Spring. Why am I considering Spring? Because lots of people tell me I should use Spring! Seriously, any time I've tried to get people to explain what exactly Spring is or what it does, they can never give me a straight answer. I've checked the intros on the SpringSource site, and they're either really complicated or really tutorial-focused, and none of them give me a good idea of why I should be using it, or how it will make my life easier. Sometimes people throw around the term "dependency injection", which just confuses me even more, because I think I have a different understanding of what that term means.

    Anyway, here's a little about my background and my app :

    Been developing in Java for a while, doing back-end web development. Yes, I do a ton of unit testing. To facilitate this, I typically make (at least) two versions of a method : one that uses instance variables, and one that only uses variables that are passed in to the method. The one that uses instance variables calls the other one, supplying the instance variables. When it comes time to unit test, I use Mockito to mock up the objects and then make calls to the method that doesn't use instance variables. This is what I've always understood "dependency injection" to be.

    My app is pretty simple, from a CS perspective. Small project, 1-2 developers to start with. Mostly CRUD-type operations with a a bunch of search thrown in. Basically a bunch of RESTful web services, plus a web front-end and then eventually some mobile clients. I'm thinking of doing the front-end in straight HTML/CSS/JS/JQuery, so no real plans to use JSP. Using Hibernate as an ORM, and Jersey to implement the webservices.

    I've already started coding, and am really eager to get a demo out there that I can shop around and see if anyone wants to invest. So obviously time is of the essence. I understand Spring has quite the learning curve, plus it looks like it necessitates a whole bunch of XML configuration, which I typically try to avoid like the plague. But if it can make my life easier and (especially) if make it can make development and testing faster, I'm willing to bite the bullet and learn Spring.

    So please. Educate me. Should I use Spring? Why or why not?

    I think you really need to try it out for a while for yourself to see if you like it and if its suitable for your project. Personally I hate it.

    While you can use XML or annotations; keep in mind that Spring takes a convention over configuration mentality. It's not necessarily a checklist of items you _have_ to address.

    While it's true that this question is rather broad, I think it should remain open. I read it as "What benefits does Spring offer for a medium-sized project?", and that's a good question.

    I highly recommend reading my favorite technical book: Spring in Action, Third Edition by Craig Walls. It's a great read and will change the way you program.

    Considering Enterprise Java, it's easier to answer what Spring doesn't do...

    Modern DI frameworks are a perfect way to make dependency resolution failures undetectable in design time.

    `Mockito.initMocks()` works well with Spring. In prod, Spring wires up the dependencies, while in tests Mockito injects your mock objects. Much easier.

    these days spring boot can be used for great effect in this scenario, rather than just the base spring framework.

    Take a look at Scala

  • Darien

    Darien Correct answer

    9 years ago

    What does the Spring framework do? Should I use it? Why or why not?

    Spring is a framework that helps you to "wire" different components together. It is most useful in cases where you have a lot of components and you might decide to combine them in different ways, or wish to make it easy to swap out one component for another depending on different settings or environments.

    This is what I've always understood "dependency injection" to be.

    I would suggest a different definition:

    "Design your objects so that they rely on an outside force to supply them with what they need, with the expectation that these dependencies are always injected before anybody asks them to start doing their usual jobs."

    Compare that against: "Each object is responsible for going out and finding everything and everybody it needs as it starts up."

    it looks like it necessitates a whole bunch of XML configuration

    Well, most of the XML (or annotation-based) stuff is telling Spring stuff like:

    • When someone asks for "HammerStore", I want you to create an instance of example.HammerStore and return it. Cache the instance for next time, since there only needs to be one store.
    • When someone asks for "SomeHammer", I want you to ask yourself for a "HammerStore", and return the result of the store's makeHammer() method. Do not cache this result.
    • When someone asks for "SomeWrench", I want you to create an instance of example.WrenchImpl, Use the configuration setting gaugeAmount and put it into the instance's setWrenchSize() property. Do not cache the result.
    • When someone asks for "LocalPlumber", I want to you create an instance of example.PlumberImpl. Put the string "Pedro" into its setName() method, put a "SomeHammer" into its setHammer() method, and put a "SomeWrench" into its setWrench() method. Return the result, and cache the result for later since we only need one plumber.

    In this way, Spring lets your connect components, label them, control their lifecycles/caching, and alter behavior based on configuration.

    To facilitate [testing] I typically make (at least) two versions of a method : one that uses instance variables, and one that only uses variables that are passed in to the method.

    That sounds like a lot of overhead for not a lot of benefit for me. Instead, make your instance variables have protected or package visibility, and locate the unit tests inside the same com.mycompany.whatever package. That way you can inspect and change the instance variables whenever you want during testing.

License under CC-BY-SA with attribution


Content dated before 6/26/2020 9:53 AM