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.
One of the best books I have ever read. i had the actual book but wanted this one for my e-reader. This is a book you will want to read more than once. I have read it about 5x and get something out of it every time.
I actually read part of this book couple of years ago, but never had an opportunity to read it all.
If you are serious about programming, this is a 'must have' piece.
Given the date this book was written, I understand the many positive reviews.
Offcourse we now are almost 2012 and 10 years of evolution in IT makes a vast difference which makes this book dated.
With today's ORM tools like JPA, (N)Hibernate, Torque, .. more than 50% of the book is irrelevant.
It might come in handy when we would like to create our own 'sort of' implementation of such tools, but why should we...
The best way to look at this book is as if you were buying a Windows Millennium book for your windows seven OS.
Some things might seem helpful and maybe even are, but there is no good reason to spend 50$ or 40 on this.
I've had this book on my wishlist for over 2 months. It's one of those things where I wait and see if I can afford it later, and then later turns into 2 months later. Let me tell you that I feel ridiculously foolish for leaving this on my wishlist for more than the time it takes to ship. If your job is in any way related to software development, you need to read this book NOW.
Surprisingly I already knew a lot about what was in this volume, but in hindsight, it was an incomplete jigsaw puzzle with the pieces laying around everywhere. To complete the analogy this book gave me the picture, of the puzzle, so I knew how the pieces should look when they fit together. I will be reading this book a second time just to burn the concepts into my brain.
As far as the literary quality, it's not dry like some references, but it's not overly exciting. If you're accustomed to reading tech ref documents and white papers then any book, like this, is disneyland in comparison. The authors organized it well, and it delivers the information in a powerful way, with lots of diagrams and code specimens to illustrate the concepts.
I'm glad this book was recommended to me, but I get the feeling that most professionals in my industry have read this volume, so it's an important thing to read.
I'm surprised to see here that the first edition, which I just finished reading after letting it collect dust for several years, is still the current edition on the market. Seven years in the software development industry is a long time, and I feel that this book could use some refactoring. (I couldn't resist.) For example, the book refers to a "Plugin" pattern because "dependency injection," an industry-wide practice of decoupling interfaces from implementations and configuring them at runtime, hadn't become a common term at the time the book was written. The "service stub" pattern, one of whose benefits is described as enhanced testing, is now better known as mock objects, and this book doesn't mention the tools and libraries that have sprung up around generating mock objects to facilitate more insular unit testing. Finally, when discussing object-to-relational-database mapping patterns, the book makes recommendations about "buying" one but makes no mention of solid open source solutions available like Hibernate.
The book's loosely edited style and almost chatty, informal delivery prevents it from attaining the academic perfection that the original "instant classic" Gang of Four design patterns book earned. There is frequent phrasing like "my preference," "here at ThoughtWorks," and (my favorite) "at the moment I don't have a strong opinion either way." Martin Fowler is cool, and is a renowned software personality, which makes it easy to tolerate the familiarity, but at times I wished for slightly more rigorous editing.
The book's examples are a blend of Java and C#, and while this works fairly well to present a language-agnostic view of the patterns, this book doesn't avoid an occasional platform-specific side trail (like the judicious use of Enterprise Javabeans vs. plain Java objects). This sort of indiscretion has often marred patterns books that would otherwise have achieved more timelessness (for example, the book "Pattern Hatching," a followup to the classic Design Patterns books, spent an entire thick middle chapter dealing with workarounds to problems that occur only in C++).
Some of the patterns in this book would not have been hard to come up with: if you've built a vertical slice of a multitier enterprise application, you've almost certainly developed some of these patterns on your own. The value of patterns literature, of course, is in how it increases our shared design vocabulary, and to the extent that it helps us know what we mean when someone talks about "doing it with a Table Data Gateway," this book is a worthy addition to the literature. Overall, though, for me the book was less a series of profound "aha!" experiences and more of a catalog of "so that's what that's called" moments. A decent effort, but the new reader should be aware that it would benefit from some updates.
I want to say first of all that this is an awesome book, one of my favorite books and a must-read for anyone who wants to be involved in enterprise computing.
Beginners can quickly learn the field's key terms and concepts and understand why things are done in a certain way. Intermediate and expert developers can use it to explore the design options available to them and revisit and modernize their designs in the future.
What do I not like about this book? Although I understand the book size limitations and the author warns readers right away about what didn't fit in, I still wish there was more coverage of mobile applications and problems unique to mobile front-ends.
Seven years after the book was originally published, and now that smartphone-based UI becoming more and more popular every year, I wish there was a second edition of this great book with more coverage of this particular area of enterprise applications.
I didn't look at this book for a long time simply because of the word "enterprise." I felt the word was too overloaded to be useful. I've heard too many managers, recruiters, and other programmers use this word to mean too many different things. Fowler defines enterprise application as "the display, manipulation, and storage of large amounts of often complex data and the support or automation of business process with that data." By that definition every system I've ever worked on has been an enterprise application.
Cons
A dense, tough read. I almost wish I was at a whiteboard or kept a notepad while reading.
Pros
Fowler gives a fantastic presentation of how to design software using databases, distributed components, etc. This is given through good narratives and anecdotes of Fowler's own experiences, and also through the patterns distilled from these.
The best thing I can say about this book is I would put it fourth in the list of books-I'd-like-anybody-I'm-working-with-to-have-read, right after to Design Patterns, Refactoring, and Extreme Programming Explained.
Summary
As with most patterns books, not everything in here is an amazing revelation, but the common approach, terminology, and ways of categorizing problems and solutions make it very valuable.
Programmers who utilize design patterns and refactoring, and who work on software systems involving distributed components and/or databases should take a look at this book.
For me, this book is an invaluable reference for building business apps.
Want help choosing a framework? Want some guidance for solving common business problems? These patterns help solve these kinds of problems.
NOTE: I have tried to find other sources for these patterns, and I have only found Fowlers website, which is really only a summary and recommends purchasing the book.
This book has examples in both Java and C#. You can certainly use these patterns in .NET.
Under .NET you are not actually forced to use the Table Model. I think the purpose of this book is to help you realize this.
There are frameworks for .NET that use the Domain Model and Data Mapper patterns, but you would never know this unless you were familiar with the patterns in this book.
For me, reading this book didn't allow me to write new code, but it did allow me to understand my choice to use a particular framework/technique over another.
This is the best book I've found on J2EE and .Net patterns. I think it's destined to become a classic. I found the discussions on when to distrbute ('sell your favorite grandmother first'), Unit Of Work, Domain Model and Data Mapper patterns extremely useful. It has changed the way I think about enterprise applications.
I think it fits somewhere between the original 'Design Patterns' book, by Gamma, et al, and a book like 'J2EE Patterns' in terms of its scope. 'Design Patterns' describes existing patterns that are applicable to any kind of application. 'J2EE Patterns' describes patterns in terms of one platform (although many of them apply to other platforms as well.) Fowler's book describes a set of patterns that work with a certain kind of application, business apps, but that are applicable to more than one platform.
It's better than the 'J2EE Patterns' book, which doesn't do a good job explaining which parts of J2EE to avoid, and which 'patterns' are in fact workarounds for problems in the platform itself. (For example, the 'Composite Entity' pattern.)
I have to strongly disagree with the first reviewer. Fowler does explain which patterns work best on which platform. The first section of the book gives a good road map for deciding which set of patterns to use for your app. He mentions explicitly that .Net pulls you in the direction of Table Module, but that with J2EE you would be less likely to use that pattern.
As far as the patterns being available in frameworks, I still find it useful to know about the patterns the framework implements. That way you know which framework to select. We recently went through an O/R mapping tool selection process. Reading the Unit Of Work, Data Mapper, Repository, Lazy Load and Identity Map chapters helped *immensely* in that process. Likewise reading the Front Controller pattern gave me some new ideas on how best to utilize the Struts framework. I totally disagree with the notion that "learning about the patterns that are associated with these frameworks will provide little value". Ignorance is definitely not bliss here.
Finally, the idea that because the book 'just' collects and names patterns that already exist somehow decreases its value is hogwash. These are tried and true patterns that many developers have found useful. Naming and clearly describing common patterns is very helpful. This is exactly what the original 'Design Patterns' book did. By this logic, I guess the original reviewer would have given 'Design Patterns' only 3 stars.
Product Details :
Hardcover: 560 pages
Publisher: Addison-Wesley Professional; 1 edition (November 15, 2002)
Language: English
ISBN-10: 0321127420
ISBN-13: 978-0321127426
Product Dimensions: 7.7 x 1.3 x 9.4 inches
More Details about Patterns of Enterprise Application Architecture, 1st edition
or
Download Patterns of Enterprise Application Architecture, 1st edition PDF Ebook
No comments:
Post a Comment