Women in Technology

Article:		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.

Showing messages 1 through 1 of 1.

• 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". :)