Rating:  - Miss the Mark
This is a book helping an architect to achieve the success of conducting a project from both managerial and technical side. Unfortunately, I don't think it serves its objectives.
The first section "Planning J2EE Applications" is ok. It explains an architect's role and functionalities in project planning, how to scope and define the project, how to estimate the timeline, etc., it generally applies to every commercial project not necessarily the J2EE projects.
The second section "Designing J2EE Applications" is not too bad either. It suggests taking "a layered approach" to J2EE application design, and talks a little bit both object model and data model, very shallow yet still common basic techniques. The author uses "Deployment Layer" which is confusing, since most people would use either service layer or facade layer instead.
Section 3 "Building J2EE Applications" is really the place that technical stuff was filled in. However, it is also the place that contains a lot of the contents that I can not agree with, or at least contradict with my experience. For example, Considering VO (value object, data transfer object would be more appropriate) as architectural component is way too heavy for me, since it is just data holder/carrier between layers, it does not impact the collaboration and interaction of the core architectural components; the business layer components are the core components and should be built first instead of any other layer components; allowing business object to manage its own transaction and database connection would defeat its minimal dependency (to achieve maximum reusability) design purpose; good design should use service layer to wrap the transaction (if it can not be applied declaratively); data access should also be transparent to business object, database connection is really implementation details (to access data from a specific data source as database) and should be encompassed in data access object itself. There are a lot of such advises that I consider technically wrong.
Section 4 "Testing and Maintaining J2EE Applications" is good start, it touches some areas such as performance and scalability briefly, but too way to lightweight to be any helpful.
Overall, the author starts with good intents but fails to accomplish the tasks. Also, I have the impression that the author is trying hard to "sell" his open source project, "CementJ".
Rating:  - Great for the big picture!
While there are many books out there to tell you how to code this or that, this book gives you a big picture view and discusses many of the items that are missing from some design considerations.
When is it best to componentize? What are the advantages of the various frameworks. This is solid advice from someone who has actually worked in the business and put into practice what he is preaching. You will find yourself reaching for this book often.
Rating: - An excellent book on the role of a J2EE Architect
Please ignore the 1-star reviewer's damning comments on this book. Comparing this book with Larman is ridiculous - to begin with this book has an entirely different focus to Larman's. I can only assume that the reviewer in question didn't really understand the value of what he was reading because he was really looking for something else from this book: something it wasn't ever intended to deliver. Thus, I imagine, he was disappointed and gave a staggeringly unbalanced view as a result.
I read this book this evening and found it an outstanding piece of work. Even if you're a whizz with UML, a genius at writing use cases, a dab hand at programming and a guru on OOAD you'll find a quite contrasting chunk of knowledge in these pages.
Yes, I'm sure that if you look around on a well-stocked technical bookshelf you'll find a lot of the material covered in this book.Much if it you won't, regardless of how big your library is.
This book is a guide to fulfilling the role of a J2EE architect, from project inception through coding standards and logging strategy on to rollout and beyond. That the author considers a large number of technical issues on top of this material is a credit to him - the book is only 280 or so pages long yet delivers, for the most part, sound guidance on technical and administrative issues alike.
The moderate page count and writing style make the book a pleasurable read. I believe you can pick up much of geniune value and finish the book within a day without your eyes glazing over.
I take issue with a small number of the author's suggestions: particularly avoiding the use of checked exceptions in favour of the unchecked variety. His argument is that code becomes less cluttered (i.e. less explicit exception handling) and that programmer productivity is enhanced. His justification for this (including references to the Sun documentation) is really rather flimsy. Although a dogmatic checked exception programmer in the past he now takes the opposite approach. To his credit the author acknowledges that his views are controversial.
My view on this subject is that life ain't so simple and there are horses for courses. Checked and unchecked exceptions each have their own merit and are each more suitable in certain circumstances. I think the author needs to re-examine his convictions: he must surely realise why checked exceptions are such a strong selling point for Java in the first place.
In many other languages unchecked exceptions are the norm, often leading to exceptionally poor exception handling practices: recoverable exceptions tend to get treated as unrecoverable at higher levels in the call stack. The semantics of an exception are often completely lost in the stack trace and understanding why an exception was thrown becomes harder...particularly as personnel changes during the project. We know where the exception happened but finding out why and its ramifications becomes much harder - human laziness shouldn't be underestimated as a source of future problems.
Nevertheless, I found the book is an excellent handbook for the practioner, apart from my major disagreement with the author over exception handling. If possible I'd take a half a star away from the five I've given because of this. However, since the book is short, useful and great value (because of it's usefulness) I'm giving it 5 stars. If it helps to offset the 1-star review a little bit then I can live with that!
Rating: - Great Book
This book is worth for the investment, a Senior Developer like me gets a great values by reading this book.
I don't know why it get One start from a reviwer, may be his expections and knowledge is very high.
Conclusion
A Great book , worth reading it, some times you can refer this book depends on your project requirement
Rating:  - The worst J2EE book available
Overall, I feel as if the author must have skimmed a number of J2EE books, and then, borrowing from these sources, compiled a hodge-podge of spotty, dated, inaccurate, and often misleading advice. Please do not waste your money on this monstrosity. If you are curious to see just how bad this book is, the book is available for free in PDF format at theserverside.com (you can also find a more detailed list of the problems, and some additional reviews thers)
FYI, the best books I have read, that cover the topics that this book was intended to cover, are: Expert One-on-One J2EE Design and Development (a.k.a. the J2EE Bible), by Rod Johnson and Applying UML and Patterns, by Craig Larman. Although these books are not free, they both contain invaluable knowledge for aspiring J2EE Architects.
|
