Book Review - 'POJOs in Action'
Author Chris Richardson, published by Manning
By now, we've all got the message that EJBs are hard to use and quite often not worth the effort. Bruce Tate's manifesto 'Better, Faster, Lighter Java' and Rod Johnson's 'J2EE Development without EJB' have set out the case against EJB for many Enterprise applications and identified Spring with Hibernate/iBATIS as a viable alternative over EJB 2 . With this in mind, I was interested to find out how Chris Richardson's book could add value.
POJOs in Action doesn't waste time reiterating the familiar arguments against EJB 2 in detail but summarises them and takes a strongly pragmatic line to help the application architect or designer to identify the best technology for the job and avoid some significant pitfalls. Whereas earlier books such as 'Better, Faster, Lighter Java' had to make the case against EJB 2 when Hibernate and Spring were still relatively immature, POJOs in action has the advantage of coming after a period of intense development in the technologies.
The book uses combinations of Spring, Hibernate, JDO (Kodo mostly) and iBATIS. The EJB 3.0 specification is also considered as of the June 2005 public draft. It goes to great lengths to provide side-by-side comparisons of JDO, Hibernate, iBATIS and, to a lesser extent, EJB 3. If you're already familiar with one of these technologies, then it should really help with identifying the similarities and differences between them.
The book is written largely from the standpoint of an application designer and takes an holistic problem-based approach rather than a technology-based approach. Chapters are focused on common design decisions for an enterprise application such as separation of concerns, organisation of business logic and locking and ORM detachment strategies. Where other books (especially those with multiple authors) can feel like a collection of disconnected essays, each on a different technology and strung together under a common banner, this book is different. It provides a highly readable, coherent and thorough tutorial in tying together Spring with a persistence layer to create a scalable server-side Enterprise application. By focusing on one design decision at a time, the implementation options and their quirks to be easily compared side by side to highlight their relative merits.
One of the stand-out features of the book for me is its adherence to test-first development, with unit tests written and discussed thoroughly before the implementations of the example application classes are presented. The testing framework used includes an extension to Junit for testing use of JDO and Hibernate written by the book's author and introduced without any fanfare. The amount of information presented on testing POJOs and ORM frameworks in particular was an unexpected bonus.
Despite being densely packed with information, I found the book to be highly readable. The author sets the context of many sections by taking the time to answers questions such as 'what's difficult about writing object persistence code?'. If I have any criticism of this book, it is perhaps that it's not clear from the description that presentation tier technologies are considered firmly out of scope.
Being written for designers/architects rather than developers means that this book is not just a compilation of documentation for various POJO technologies. By taking the time to explain the trade-offs with each technology and the pros and cons of the patterns discussed, the reader benefits from the experience of the author. If you're interested in the relative merits of Hibernate, JDO and iBATIS for implementing an offline optimistic locking strategy (or many other patterns found in Martin Fowler's 'Patterns of Enterprise Application Architecture') , then this is the book for you.
Conclusion
I really liked this book. It was an easy and informative read with a good balance of high-level design and low-level detail that created a compelling argument that Enterprise Application development with POJOs is realistic but like all development involves trade-offs and has a few pitfalls for the inexperienced.
