Announcement Announcement Module
No announcement yet.
Spring usage pattern question Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Spring usage pattern question


    Let's say we have a case where we have our entire application wired together and a single invocation of the Spring container is done in the main() method.

    In the core pipeline of this application, let's say we have code which needs a different implementation of an interface at run time.

    We've done this in a fashion where we leverage container calls to look for a specific bean's implementation at run time. The advantages of this that we liked is that the pipeline code is untouched and therefore doesn't need additional testing and in order to support a new implementation we simply create a new bean definition and write the implementation class and we're done.

    Is this considered bad practice to invoke the Spring container in the application like this? I understand a disadvantage to this is that the portion of the pipeline code is coupled to the container.

    Thanks for any direction you all can provide.

  • #2
    Any Spring experts out there who can/want to comment?


    • #3
      I think it's a perfectly acceptable approach. The Spring application context is, after all, an object factory, which is exactly how you're using it. Sure you're creating a coupling to the container, but what are the odds that you will change your container tomorrow? If that's a real possibility, you can always abstract this call behind another layer of indirection.

      We've used this approach in a previous project so that domain objects could lookup dependencies at runtime. The main inconvenient was that we had to use a singleton to load and provide access to the application context, but aside from that it met our requirements. I would use a different solution today (@Configurable with AspectJ), but I don't regret the choice we made back then.



      • #4
        Originally posted by spiff View Post
        I would use a different solution today (@Configurable with AspectJ)
        Hi Spiff,
        Can you talk a little bit more about this solution? I can see why @Configurable would be helpful but I don't see how you would use aspectj Thank you


        • #5
          Spring can inject dependencies on objects that aren't managed by the application context, for example objects created with the 'new' operator. To do this, you can annotate your class with @Configurable and declare its dependencies either through annotations (@Resource or @Autowired) or through a prototype-scoped bean definition in the applicationContext.xml file. Since annotations don't do anything by themselves, you then have to use AspectJ compile-time or load-time weaving to add the DI behavior after the class constructor completes.

          The AOP-based solution does the same thing as the singleton-based one, but it has the advantage of being completely transparent to your code, removing a dependency to the container and removing a singleton.

          More info here:



          • #6
            Hi Sipp,
            hmmm so in this case one would not program against interfaces (one of the best practices) but actual concrete implementations (classes) or am I missing some thing?
            Thank you for the fast reply



            • #7
              Coding to interfaces is indeed a good practice, but that doesn't mean you should code exclusively to interfaces. Creating an interface, an implementing class and a factory doesn't always bring you enough benefits to warrant the additional overhead, and you may be better off just developing a concrete class and simply instantiating it with the new operator. This is often the case in your domain model.

              Last edited by spiff; May 16th, 2008, 12:46 PM.