- Hardcover: 560 pages
- Publisher: Addison-Wesley Professional; 1 edition (November 15, 2002)
- Language: English
- ISBN-10: 0321127420
- ISBN-13: 978-0321127426
- Product Dimensions: 7.4 x 1.3 x 9.3 inches
- Shipping Weight: 2.5 pounds (View shipping rates and policies)
- Average Customer Review: 126 customer reviews
- Amazon Best Sellers Rank: #18,969 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Patterns of Enterprise Application Architecture 1st Edition
Use the Amazon App to scan ISBNs and compare prices.
Frequently bought together
Customers who bought this item also bought
Customers who viewed this item also viewed
From the Back Cover
The practice of enterprise application development has benefited from the emergence of many new enabling technologies. Multi-tiered object-oriented platforms, such as Java and .NET, have become commonplace. These new tools and technologies are capable of building powerful applications, but they are not easily implemented. Common failures in enterprise applications often occur because their developers do not understand the architectural lessons that experienced object developers have learned.
Patterns of Enterprise Application Architecture is written in direct response to the stiff challenges that face enterprise application developers. The author, noted object-oriented designer Martin Fowler, noticed that despite changes in technology--from Smalltalk to CORBA to Java to .NET--the same basic design ideas can be adapted and applied to solve common problems. With the help of an expert group of contributors, Martin distills over forty recurring solutions into patterns. The result is an indispensable handbook of solutions that are applicable to any enterprise application platform.
This book is actually two books in one. The first section is a short tutorial on developing enterprise applications, which you can read from start to finish to understand the scope of the book's lessons. The next section, the bulk of the book, is a detailed reference to the patterns themselves. Each pattern provides usage and implementation information, as well as detailed code examples in Java or C#. The entire book is also richly illustrated with UML diagrams to further explain the concepts.
Armed with this book, you will have the knowledge necessary to make important architectural decisions about building an enterprise application and the proven patterns for use when building them.
The topics covered include:
About the Author
Martin Fowler is an independent consultant who has applied objects to pressing business problems for more than a decade. He has consulted on systems in fields such as health care, financial trading, and corporate finance. His clients include Chrysler, Citibank, UK National Health Service, Andersen Consulting, and Netscape Communications. In addition, Fowler is a regular speaker on objects, the Unified Modeling Language, and patterns.
Top customer reviews
There was a problem filtering reviews right now. Please try again later.
As of May 3, 2011, the issue with the missing figures/diagrams seems to be fixed.
The more i read the more I was frustated and reading further.
The sample code doesnt match the explanation provided. The sentences are so vague seems that the author was drunk while writting this book ..
The best part of the book is the title very fancy and inviting .. but the book is really a crap.
I would recommend
Framework Design Guidelines
Ramesh Babu Veeramani
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.
One complaint I do have (and because this book is from 2002 I don't take stars away) is that it seems to ignore some modern ideas about Dependency Inversion and testability. In 2015 we'd probably make a lot of design decisions around the ability to test classes. Testing usually involves injection of abstract dependencies, so many systems are designed with that in mind. Several of the patterns in this book explicitly go against this idea. Repository is one, and Active Record is another. In fact, his example code for Active Record uses a Repository internally as a static global to look up DB connectivity information. It's worth reading up on why people typically don't use static globals like Repository (and why they shy away from derivative concepts like Service Locator, not discussed in this book), because this is pretty important stuff for modern design.
BUT THEN AGAIN, plenty of people make the argument that modern unit testing isn't being done right. If you look at something like Ruby On Rails which makes heavy use of Active Record, the database isn't typically isolated out of tests (it's the tester's responsibility to provide a speedy local DB). Supporters of Rails might say that the design is better and more elegant for the use of Active Record, and trying to change it to support unnecessary testing would be a problem. My point is, there is a lot of complicated discussion to be had on this issue, and this book doesn't really include any of it (because it was written and published before many of these issues became things).
I also find that some of the code examples are so small that they venture into the realm of being trivial, or they don't demonstrate some of the flexibility inherent in these patterns. I do like that the book switches between Java and C# for its examples, to avoid being tied to one language, but the similarity between Java and C# help to make it so most readers should be able to follow along even if they only know one language or the other.
In summary, despite showing its age this book is an indispensable foundation text and any developer above the mid-level probably would benefit from giving it a read through. The real benefit comes if you start with these ideas and then research how these ideas have evolved over time.