on February 8, 2004
Overall, I was disappointed by this book. I develop business applications, and I was hoping this book would provide practical insights about such applications, more specifically in the database/web realm. While this book does contain some interesting pieces of information, it really is not of immense value to a developer such as myself. Here's why:
This book is a bit of a mishmash of different topics, but the vast majority of it (I'd say 75% or more) consists of ideas for object-relational mapping. Since most developers would use existing tools for object-relational mapping (in the Java realm, see Hibernate, JDO, etc.), I fail to see the real usefulness of this book for most developers building business (web) apps. Further, this kind of book encourages people who don't have the necessary expertise to try rolling their own OR mappers, which is simply not a good idea.
It's too bad, because the book starts off promisingly enough with 3 general approaches to business apps: Transaction Script: The procedural/transactional approach; Domain Model: The OO approach; and Table Module: The data-cetric approach. So far so good. Unfortunately the book then seems to steer off to the topic of "Fun With OR Mapping." It's not as sexy, but I think that's perhaps what the title of this book should have really been! The book then goes on to talk about different ways to architect Web applications, again mostly getting into how to develop framework code, which one largely would take for granted if one is deciding which framework to use rather than rolling one's own. Finally the book talks a bit about locking strategies (pessimistic, optimistic) and then presents a few generic items (e.g. the concept of a Money class or a Registry class).
Only a very small fraction of this book will be useful to a non-framework developer. Also, even though this book claims to be technology-agnostic, it seems rather firmly planted in the Java world. I'm not convinced an ASP/ADO.NET developer would find it particularly useful, for example. I think there is an important need to demonstrate how to put together solid business applications. I'd love to see a book of recipes that says "here's how to develop an ASP/ADO.NET app; here's how to develop using EJB; here's how to develop using Hibernate..." but without all the distracting details of how to implement the whole solution from scratch -- Basically I want a book that relies on the idea that frameworks are out there, but focuses the developer on how to choose a framework and how to take advantage of frameworks to produce solid, maintainable solutions.
Lastly, I would say Core J2EE Patterns from Sun Press is a more useful book for the Java/J2EE crowd, though it too suffers from framework-itis.
on June 28, 2003
This book has been getting a lot of hype -the followup to Fowler's seminal Refactoring, enterprise edition of the GoF, etc etc.
It's a dense and informative read. If you didnt know anything about cricket, you will by the end, as all its examples are basd on the game. I, sadly, find cricket deadly dull as a consequence of having it force fed at me in the UK educational system. This may bias me against the examples somewhat.
As to the content, well, it is a set of patterns focused on 'enterprise' applications. In this context, enterprise means server-side code connected to a database, usually with a Web Front end. Martin goes into superb depth on how to map from databases to java and .net objects, making you think about whether or not the stuff that your framework of choice gives you is the right tool for the job. Sadly, all that does is make you more aware of the failings of EJB, JDBC, whatever .NET has. Because, unless you are going to roll your own database bridge by hand, you are going to have to run with what they give you -whether it [stinks] or not.
I dont do much O/R mapping. I hand it off to tools like Castor and worry about my real problems: shipping web services to implausible deadlines to be managed by an operations team that phone me whenever something goes wrong. So my problems are web service related 'good API design', and 'executional patterns': how to design code that is easily tested, what is a good strategy for implementing configuration information, what is a good XML format for future flexibility. I also have to worry about the client side: how to architect a client that works well over long haul and intermittent links, and how to present this to the user.
Martin's book doesnt cover these kind of problems. I do like his critique of Entity EJBs (as opposed to session beans), where he observes that because EJBs are all distributable, people tend to do just that, leading to performance problems that are very profitable to him as a consultant.
The implicit message is that these days, he is spending his time tuning object to DB linkages, and not worrying about all the other aspects of the problem. Another reviewer mentioned security, but my concern is about designing for high availablity, a series of practises that focus on redundancy, caching, and interdependencies and self-diagnosis of faults, rather than caring about minutae of O/R binding.
So I'm giving the book 3-stars, as it doesn't suit my problems. Maybe it suits other people better.
on September 6, 2003
Book Titles That Make a Good Sell
There were times when Enterprise, Architecture
and Patterns titles sold very well, even if the books
themselves did not offer a big deal of information...
If you are looking again for a glossary type of patterns,
plus a ton of source code and UML diagrams, but
neither Architecture nor Enterprise, you may consider
adding this book to your bookshelf. It may sit there for a
while until you find some use for it.
It is a bit difficult for me to identify the book
with Enterprise and Architecture even if its title
suggests so, and it is more difficult for me to understand
how the first 106 pages are affiliated to the rest of the
book, called Part 2, the Patterns.
Here are some points to consider:
1. WEB TECHNOLOGIES? If you are looking for
Enterprise Architecture Patterns, you will be surprised to
find here a strong affiliation between Enterprise and Web
technologies. Coupling Web technologies and Enterprise may
not be reflecting today's real world. Surprisingly, only
about 10%-15% of our Enterprise technologies are Web related,
the rest are still legacy technologies.
2. ARCHITECTURE ENTERPRISE PERSPECTIVE: The author
introduces a collection of patterns, which suggest solutions
to enterprise architecture challenges, but the perspective is
shallow and single dimensional. This is the same as looking
at a problem from a one inch distance rather than seeing the big
picture first. This leads me to believe that the book targets
mostly developers rather than designers and architects.
3. ENTERPRISE ARCHITECTURE AND DATABASE CONCEPTS: The
author dedicated many topics and references to database
issues such as Database Connections, Data Sources, Meta Data,
Optimistic and Pessimistic Locking etc. The book is too heavy
on database solutions, rather than pointing first to the
Problem Domain. It is a kind of a Backwards solution to
enterprise architecture challenges.
4. THE DISTRIBUTED OBJECTS DILEMMA: The suggestion not
to distribute objects on networks is not a careful
proposition in today's technology. The distribution of your
processes, objects, models and subsystems contribute a great
deal to enterprise reusability. If the author bothered to
take a look at today's application server technologies, he would
notices that many vendors already introduced a workable
solution to delinquencies caused by object distribution such
as Replica Aware Stubs or Object Replication techniques.
on June 23, 2003
I am a fan of Fowler's and especially his "Refactoring" book, which I also rate as a must read for the serious programmer.
Fowler's new book is an attempt to do for Enterprise Application Architecture what "Design Patterns" (i.e., GOF) did for OOP.
Unfortunately,while it is an excellent book, there are issues...
1)First, Design Patterns is a very dense and scholarly read. It is also, frankly, a difficult read. However, after you have spent a couple of days trying to digest a pattern from Design Patterns, you realize, in many cases, you have had an experience with something profound. Even the GOF authors, in the preface, attempt to console readers by admitting "We didn't understand it all on the first writing!". Fowler's book, by contrast, is not on the same level, and can be understood on a first read. Perhaps this is what other reviewers were sensing when they indicated it was for the novice architect?
2) Fowler does NOT address security. How then,does the word "Enterprise" get the priviledge of adorning the title of his book? Enterprise design should be secure design. But, this will usually require a trade off --- more secure, less performance...or less secure, more scaleable...Fowler does not consider this. Example: A chapter is devoted to the "Table Data GateWay" pattern. The gateway pattern might be OK for J2EE...but it is not the most secure, or the best for performance,in .Net... The problem is it constructs its SQL statements in line, rather than using stored procedures. This allows SQL insertion attacks if your coders are sloppy, and also does not take advantage of the precompiled nature of sprocs.
3)There is a J2EE bias. This probably is a good thing as the J2EE architectures tend to be more mature and contain good ideas...but you should be aware of it if you are a .NET programmer. Not all of the patterns will be immediately useful to .NET, but will require a careful implementation.
4)Fowler passes on some of the tough questions. On page 93, while discussing RPC calls versus XML based messaging, he says "my preference is for a message - based approach that's inherently asynchronous." I agree. (RPC style is not the really suited for async, whereas document style messaging is) He then says it is too large of a topic, so does not cover it. Well, if it is the best way, it needs to be covered in an Enterprise level book, no?
While I may seem to be critical of Fowler's book, I really think it is excellent with fine ideas. But, especially if you are from .Net, implement the patterns with care, and then only you have checked against Microsoft best practices. This is not to say Microsoft is always right, but get the second opinion anyway.
on December 19, 2002
When someone says, "Unit Of Work, Domain Model and Data Mapper patterns extremely useful. It has changed the way I think about enterprise applications.", then these people shouldn't be writting enterprise applications to begin with.
Most smart developers and architects already knew these patterns and if you didn't from working on enterprise applications in the past (either writting them or reading other programmer's code), then you should probably go find another job.
The wealth of this book is not in gaining the knowledge about the patterns but it's to promote a common vocabulary in the industry among other programmers so you can communicate in the same language. Thus, If you actually 'learned' a lot of stuff from this book, you should really question how good of a software designer you really are (because that means you really didn't know a whole lot).
Patterns like Domain Model are very, very obvious - It's how we build OO programs to begin with and if this initiated some kind of paradigm shift, then perhaps you should be reading other books. If you are one of these kinds of readers, first learn how to actually use object oriented languages and learn how to refactor before you read this book because you aren't intelligent enough to appreciate what this book is really used for to begin with.
With common knowledge of OO programming and the discipling to refactor code, you should *discover* many of these patterns on your own instantly seeing as it's a fairly systematic process.
This book is for people who want to talk the same talk and that's all. If you want to learn something, you can learn the principles behind the patterns and these books have been out for 5-10 years already.
on December 1, 2002
This is the only book I have encountered that describes .NET patterns. This is particularly useful when attempting to gain an understanding of how application architectures differ between .NET and J2EE.
The Java patterns are also very interesting, especially when compared with those described in the J2EE design pattern specific books. Note that this book might best be described as "Enterprise Design Patterns for non J2EE systems". Some of the patterns can be used to implement DAOs (perhaps for a BMP entity bean). Many others are not really J2EE compliant (eg Identity Map). To some extent, the patterns would only form part of the J2EE container implementation.
(However, "Server Component Patterns" by Volter, Schmid and Wolff provides a better coverage of the design patterns applicable to the design of a J2EE container).
This book would certainly be useful to any one wrestling with the "are EJBs useful" question. It provides an excellent description of all the issues that need to be resolved for an industrial strength implementation.
Unfortunately, there are many edit problems.
For example, The MVC text uses both presentation and view interchangably. In one sentence, a typo causes this to be confused with model ("Fundamentally presentation and view are about different concerns" pg 331)
Other problems merely affect the sentence construction. (eg ".. and they people specialize in ..." pg331`)
These problems are the only reason that I did not give a 5 star rating.
on November 23, 2002
First, I'd like to say that I think Marin Fowler is awesome. I've been a long time fan of his and I really enjoy his talks and his books. So when you read this review, you can tell that it pains me to write what I have to say. I don't want to rip apart his book so that he potentially sells fewer copies - that's not my intention at all. By writing 3 books myself, I appreciate that authors don't make a lot of money for developing the book itself. Usually people like Martin write books for the experience and to generally help people.
That being said, many developers will unfortunately not find this book very useful. Many of the patterns Martin shows us have a lot of dependency on the platform you are using to implement the application. For instance, if you use Microsoft's .NET platform, you are going to be leaning towards a Table Module instead of a Domain Model. If you do not use a Table Module, you will not be able to take advantage of a considerable amount of functionality that is provided for you within the .NET platform. In Java, the same is true; the Table Module doesn't look as appealing if you are using EJBs, JDO or even Hibernate - you won't ever consider it.
Many of the patterns in the book have this characteristic described above, so architects won't actually learn anything from them. In other words, architects will not be able to take advantage of these alternate design patterns without some initial headaches that are often not worth it because the platform they use restricts and penalizes their usage.
Another complaint about the book is that many of the patterns are already available as frameworks. For instance, many of the presentation patterns are handled by frameworks like Struts or Webwork. In these cases, learning about the patterns that are associated with these frameworks will provide little value. These patterns have already been discussed many times before in other books like "Advanced Java Server Pages" for example.
The same could also be said for persistence frameworks of O/R mapping tools. There is literally over a 100 pages (in a 500 page book) that talk about lazy loads, unit of work, locking strategies, metadata patterns and inheritance mappings. Although sometimes they are useful, in most situations the developers would be abstracted away from all these underlying mechanics using a good persistence framework or O/R mapping tool. I realize not all that the this is true, but implementing Martin's suggestions would take a month or two alone if you didn't buy anything off the shelf - that's too much time to waste. Martin should have talked more about these tools and the patterns they currently implemented instead as this is a more pragmatic approach.
Martin also doesn't talk about the load-on-startup servlet that can be used to store application-scoped values in the ServletContext (for J2EE systems) in his Registry pattern. This was unfortunate because many non-ejb systems use this approach. Considering the book advocates using POJOs, JDO or JDBC instead of EJBs (which is sound advice in practice for most systems), they didn't cover the registry alternates for this approach. Many of us use containers like Resin because they are extremely fast and have no need for EJB development.
Coming from three different environments myself (PHP, .NET and J2EE), I was disappointed that I didn't learn anything from this book. I had, in fact, learned about many of these patterns on my own, but didn't exactly know what they were called. This left me disappointed, but it's not Martin's fault. I don't mean to build me up that I know everything, but I think I've reached a plateau when it comes to designing and architecting systems - I'm good at it. If you happen to be a good designer too and you think you might want to broaden your knowledge, then this book won't help in those areas. If this book doesn't, I don't think you'll find another book that will either. So again, this isn't Martin's fault.
Now before you say something, Martin explicitly states in his book that many experienced designers *will not* learn much. He mentions more than a few times that this book is meant to enhance the communication between architects and designers more than anything and that it is meant to be a documented repository of patterns that we know as an industry and use over and over. I completely agree with these statements. Thus, the book has value in these regards and it will definitely help the industry evolve and mature.
I know I've said some negative things about the book, but let's face it - this is Martin Fowler! The quality and style of the writing is top notch and the organization of the information couldn't have been better. The explanations and examples are very clear and this book is what it claims to be. In this respect, the book should be regarded as the best in its market.
I would advocate purchasing this book in combination with "EJB Design Patterns" and "Expert One-On-One: J2EE Design and Development" for the J2EE developer. As for you .NET folks, I have no idea. From experience, I suspect that .NET developers will have even less use for this book since Microsoft has limited your choices about design in favour of simplifying the platform. That's one of the major differences between J2EE and .NET, and Martin can't control that either.
Overall, this is a good book. I give it only 3 stars, however, because of the initial problems described above.
on March 31, 2003
I'm a little surprised by the number of rave reviews about this book. The book is ok, but there are some annoying problems that let it down. For starters, the lack of decent proofreading before going to print ï¿½ itï¿½s an expensive reference book and I would expect better quality. Secondly the colloquial vernacular only impedes, not complements the reading. Thirdly, the patterns seemed fewer than I expected and covering only elementary issues. I suppose the audience is primarily for enterprise architecture novices.
on June 17, 2003
Martin Fowler is a great speaker and presenter. I felt this book felt short of his image and wasn't all that good. If Martin were not the author of this book, I suspect that it would not have sold any copies.
on September 14, 2003
This is a well written book, with resonable explanations and samples. If you are familiar with patterns by GOF and distrubuted architecture patterns then there is not much new in this book. If not this is a must read and serves as a basis for platform independant review of a good cross section patterns to be applied in enterprise architecture, in which RDBMS's are always a key component. My expectations were high based on Mr Fowlers earlier works, not to say this is a lesser work, just it has been well covered before this work by Mr Fowler.