| Article: |
POJO Application Frameworks: Spring Vs. EJB 3.0 | |
| Subject: | Spring and/or EJB3 | |
| Date: | 2005-07-03 22:39:02 | |
| From: | MichaelYuan | |
|
Response to: Spring and/or EJB3
|
||
|
Hmm, just a quick point -- EJB 3 and Spring both provide easy-to-use APIs on top of existing persistence solutions (Hibernate, Toplink, JDBC etc.) I do not think it is sensible to use EJB 3 as a persistence plug-in for Spring -- it forces two layers of abstraction and defeats the whole "standard" advantage of EJB 3.
|
||
Showing messages 1 through 1 of 1.
-
Spring and/or EJB3
2006-10-05 11:27:24 mrpantsuit [View]



When making statements about “tying”, please stick to the aspects of Spring where this can actually occur: programmatic transaction management; use of Spring DAO templates and supports, etc. Also, remember that these are aspects purely optional, as is most everything in Spring.
Also, Spring XML config looks nice and complicated in your examples, but remember that most of those XML stanzas will occur only once (transaction manager definition, etc.). The overwhelming majority of XML stanzas that developers will add to a Spring XML config are stupidly simple:
<bean id="myService" class="mypackage.MyServiceImpl">
<property name="anotherService" ref="anotherService"/>
<property name="yetAnotherService" ref="yetAnotherService"/>
</bean>
I also agree with the other posters that annotations in a bean is a half-baked way of accomplishing DI. Once you add an EJB3 specific annotation to your POJO, it’s not really a POJO anymore, is it? I don’t know enough about it, but why didn’t they design EJB3 similar to Spring. Couldn’t they have come up with a solution that included the flexabillity, lightness, and non-intrusive nature of Spring with the scalability and distributability (not a word) of EJB3?