Women in Technology

Hear us Roar

  POJO Application Frameworks: Spring Vs. EJB 3.0
Subject:   Misses the mark on Spring
Date:   2005-07-02 18:09:57
From:   RHassel
Spring's independence from the application server is a benefit, not a liability. Our web GUI runs in an application server, sure. But what about console utilities, automated unit tests, installation components, etc. that need access to the persistence layer and business service objects, too? App servers are not the right tool for every job. Fortunately, Spring lets me run inside or outside of a J2EE container--it's all a matter of runtime configuration.

Also, the author overplays the "vendor lock-in" myth. The whole point of leveraging POJOs and DI is to avoid API coupling. Not a single one of my business service classes imports a Spring package. And yet, they reap the benefits of transaction management, persistence session management, configuration setting injection and more through Spring.

Full Threads Newest First

Showing messages 1 through 2 of 2.

  • Misses the mark on Spring
    2005-07-03 22:49:17  MichaelYuan [View]

    Like I said, if you need to assemble your own app services, then Spring is a better choice, as each EJB 3 implementation is optimized for a special app server for better performance and user experience. But I disagree that unit testing is an advantage for Spring -- the new generation of lightweight EJB 3 containers makes in-container testing easier (and of course more accurate) than using mocks -- give it a try!

    In the case of your Spring application, yes, you have managed to create Spring-independent "business service" classes (IMHO, EJB 3 session bean POJOs are a lot simpler). But I am sure your application as a whole still has various dependencies on Spring (XML and helper classes). You might be well justified to have faith in Spring vendor. But I am also right in claiming that Spring causes "vendor lock-in". :)
    • Misses the mark on Spring
      2006-10-05 11:37:52  mrpantsuit [View]

      The whole point of unit testing is to test a single "unit", not "this unit + that unit". The need to test in a container is an indication of a flawed architecture.

      Mock testing w/ EasyMock is...well...easy.

      The only difference between a Spring bean and an EJB3 EJB is the addition of EJBE annotations. How does adding something make it simpler?

      I would recommend Spring2/Hibernate or Spring2/JPA for most apps and reserve EJB3 for very complex apps requiring vast scalability and distribution.