Hi Raghu and Jonathan, Does your book contain justification of opting for EJB3.0 over Spring? Now with Spring being accepted as the standard in many companies (I know of many in the SF bay-area), and with Rod Johnson's popularity as the Spring author and with his anti-EJB books - we need solid comparison between EJB3.0 and Spring - under-scoring the advantages (and disadvantages) of using EJB3.0 over Spring. In addition, the advantages of using EJB3.0/JPA over Struts-2/POJO/Hibernate backend.
On a separate note, does your book talks about the design patterns that are already embedded in the EJB3.0 framework? Does it say which patterns one should and should NOT use with the framework? Thanks, Sudd
Hi Sudd- Yes, the question of Spring vs. EJB 3 is one I wish we had addressed head-on in the book. Due to various constraints, we could not address everything -- we'll save this topic for the next edition .
I posted my general thoughts on this in this thread. As a further comment, I'll say that it is to the JSR-220 expert group's credit that it is incorporating technologies such as Spring/TopLink/Hibernate into the EJB 3 spec and turning them into standards. I would expect further advances in these areas, and in the "next" hot areas, to be incorporated into the spec in the future.
Regarding patterns and best practices, this is a book primarly about learning and understanding the EJB 3 technology so you can decide how to put it to use. We don't emphasize patterns per se, and we try to stay agnostic to controversial topics in general, such as annotations vs. XML. We try to present the information you need to make your own decision on this type of issue.
Throughout the book we discuss choices you can make depending on the needs of your particular application. For instance, the discussion of entity inheritance covers a number of considerations based on how you plan to use your entities, how they might evolve over time, and so on. We also explain and provide examples of the session facade pattern, id generator and optimistic locking usage, transaction management, and many others. And of course, the MVC pattern is assumed throughout our design discussions.
Joined: Oct 23, 2002
Thanks for the informational thread/link. It explained a lot.