POJO Application Frameworks: Spring Vs. EJB 3.0
Subject:   Spring and/or EJB3
Date:   2005-07-02 21:49:36
From:   markstg
First off, EJB 3 is a great move forward, however we have to remember its not even FINAL yet.

Secondly, I think that EJB3 and Spring could very well be used together? I could see this as a strategy for alot of shops that still like Spring, and have management that feels more comfortable with going with "standards" (whatever that really means nowadays).

EJB 3 Persistence will just be another supported Data Access strategy supported by Spring, as well as the EJB 3 Session Bean model might be used in favor of Spring-managed business services.
However, the IoC container provided by Spring is much more advanced than the very simple DI provided by EJB3. So for managing fine-grained objects, Spring is a clear winner in that space.
So DI for things like lists, maps, etc. are not supported in EJB3 (from what I can tell).

Spring's XML configuration is pretty sensible and its getting less verbose in the coming releases. Again, the Spring examples are not using the new shorthand XML notations.

In my personal opinion, Spring really was providing for the gaps in the EJB 2.x model... EJB3 will be loads better, EJB 3 persistence great... EJB3 Session Beans.. ok whatever, not really providing anything new there in my opinion.
I still alot of benefits to using Spring for an overall application framework, versus EJB3.

Full Threads Oldest First

Showing messages 1 through 2 of 2.

  • Spring and/or EJB3
    2005-07-03 22:39:02  MichaelYuan [View]

    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.

    Of course, if you love Spring XML and have to tie your application architecture to Spring DI. Then, you should just use Spring and ignore EJB 3 altogether. :)
    • Spring and/or EJB3
      2006-10-05 11:27:24  mrpantsuit [View]

      Tying app architecture to Spring DI is impossible. The principal philosophy of Spring is loose coupling (the opposite of “tying”). Have you ever seen a bean in a Spring-based app? They have no Spring classes whatsoever. They merely have properties whose types are app interfaces. These beans have no knowledge the outside world beyond the interfaces of the app services they require.

      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"/>

      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?