did-you-know? rent-now

Amazon no longer offers textbook rentals. We do!

did-you-know? rent-now

Amazon no longer offers textbook rentals. We do!

We're the #1 textbook rental company. Let us show you why.

9780321127426

Patterns of Enterprise Application Architecture

by
  • ISBN13:

    9780321127426

  • ISBN10:

    0321127420

  • Format: Hardcover
  • Copyright: 2002-11-05
  • Publisher: Addison-Wesley Professional

Note: Supplemental materials are not guaranteed with Rental or Used book purchases.

Purchase Benefits

  • Free Shipping Icon Free Shipping On Orders Over $35!
    Your order must be $35 or more to qualify for free economy shipping. Bulk sales, PO's, Marketplace items, eBooks and apparel do not qualify for this offer.
  • eCampus.com Logo Get Rewarded for Ordering Your Textbooks! Enroll Now
  • Write a Review Icon Write a Review
  • Complimentary 7-Day eTextbook Access - Read more
    When you rent or buy this book, you will receive complimentary 7-day online access to the eTextbook version from your PC, Mac, tablet, or smartphone. Feature not included on Marketplace Items.
List Price: $69.99 Save up to $17.50
  • Buy Used
    $52.49
    Add to Cart Free Shipping Icon Free Shipping

    USUALLY SHIPS IN 2-4 BUSINESS DAYS

    7-Day eTextbook Access 7-Day eTextbook Access

Supplemental Materials

What is included with this book?

Summary

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: Dividing an enterprise application into layers The major approaches to organizing business logic An in-depth treatment of mapping between objects and relational databases Using Model-View-Controller to organize a Web presentation Handling concurrency for data that spans multiple transactions Designing distributed object interfaces 0321127420B10152002

Author Biography

Martin Fowler is the Chief Scientist for ThoughtWorks

Table of Contents

Preface.
Who This Book Is For.
Acknowledgements.
Colophon.

Introduction.
Architecture.
Enterprise Applications.
Kinds of Enterprise Application.
Thinking About Performance.
Patterns.
The Structure of the Patterns.

Limitations of These Patterns.

I. THE NARRATIVES.


1. Layering.
The Evolution of Layers in Enterprise Applications.
The Three Principal Layers.
Choosing Where to Run Your Layers.

2. Organizing Domain Logic.
Making a Choice.
Service Layer.

3. Mapping to Relational Databases.
Architectural Patterns.
The Behavioral Problem.
Reading in Data
Structural Mapping Patterns.
Mapping Relationships.

Inheritance.
Building the Mapping.
Double Mapping.

Using Metadata.
Database Connections.
Some Miscellaneous Points.
Further Reading.

4. Web Presentation.
View Patterns.
Input Controller Patterns.
Further Reading.

5. Concurrency (by Martin Fowler and David Rice).
Concurrency Problems.
Execution Contexts.
Isolation and Immutability.
Optimistic and Pessimistic Concurrency Control.
Preventing Inconsistent Reads.

Deadlocks.
Transactions.
ACID.
Transactional Resources.

Reducing Transaction Isolation for Liveness.
Business and System Transactions.
Patterns for Offline Concurrency Control.
Application Server Concurrency.
Further Reading.

6. Session State.
The Value of Statelessness.
Session State.
Ways to Store Session State.

7. Distribution Strategies.
The Allure of Distributed Objects.
Remote and Local Interfaces.
Where You Have to Distribute.
Working with the Distribution Boundary.
Interfaces for Distribution.

8. Putting it all Together.
Starting With the Domain Layer.
Down to the Data Source.
Data Source for Transaction Script.

Data Source Table Module (125).
Data Source for Domain Model (116).
The Presentation Layer.
Some Technology-Specific Advice.
Java and J2EE.

.NET.
Stored Procedures.
Web Services.
Other Layering Schemes.

II. THE PATTERNS.


9. Domain Logic Patterns.
Transaction Script.
How It Works.

When to Use It.
The Revenue Recognition Problem.
Example: Revenue Recognition (Java).
Domain Model.
How It Works.

When to Use It.
Further Reading.
Example: Revenue Recognition (Java).
Table Module.
How It Works.

When to Use It.
Example: Revenue Recognition with a Table Module (C#).
Service Layer(by Randy Stafford).
How It Works.

When to Use It.
Further Reading.
Example: Revenue Recognition (Java).

10. Data Source Architectural Patterns.
Table Data Gateway.
How It Works.

When to Use It.
Further Reading.
Example: Person Gateway (C#).
Example: Using ADO.NET Data Sets (C#).
Row Data Gateway.
How It Works.

When to Use It.
Example: A Person Record (Java).
Example: A Data Holder for a Domain Object (Java).
Active Record.
How It Works.

When to Use It.
Example: A Simple Person (Java).
Data Mapper.
How It Works.

When to Use It.
Example: A Simple Database Mapper (Java).
Example: Separating the Finders (Java).
Example: Creating an Empty Object (Java).

11. Object-Relational Behavioral Patterns.
Unit of Work.
How It Works.

When to Use It.
Example: Unit of Work with Object Registration (Java) (by David Rice).
Identity Map.
How It Works.

When to Use It.
Example: Methods for an Identity Map (Java).
Lazy Load.
How It Works.

When to Use It.
Example: Lazy Initialization (Java).
Example: Virtual Proxy (Java).
Example: Using a Value Holder (Java).
Example: Using Ghosts (C#).

12. Object-Relational Structural Patterns.
Identity Field.
How It Works.

When to Use It.
Further Reading.
Example: Integral Key (C#).
Example: Using a Key Table (Java).
Example: Using a Compound Key (Java).
Foreign Key Mapping.
How It Works.

When to Use It.
Example: Single-Valued Reference (Java).
Example: Multitable Find (Java).
Example: Collection of References (C#).
Association Table Mapping.
How It Works.

When to Use It.
Example: Employees and Skills (C#).
Example: Using Direct SQL (Java).
Example: Using a Single Query for Multiple Employees (Java) (by Matt Foemmel and Martin Fowler).
Dependent Mapping.
How It Works.

When to Use It.
Example: Albums and Tracks (Java).
Embedded Value.
How It Works.

When to Use It.
Further Reading.
Example: Simple Value Object (Java).
Serialized LOB.
How It Works.

When to Use It.
Example: Serializing a Department Hierarchy in XML (Java).
Single Table Inheritance.
How It Works.

When to Use It.
Example: A Single Table for Players (C#).
Loading an Object from the Database.
Class Table Inheritance.
How It Works.

When to Use It.
Further Reading.
Example: Players and Their Kin (C#).
Concrete Table Inheritance.
How It Works.

When to Use It.
Example: Concrete Players (C#).
Inheritance Mappers.
How It Works.

When to Use It.

13. Object-Relational Metadata Mapping Patterns.
Metadata Mapping.
How It Works.

When to Use It.
Example: Using Metadata and Reflection (Java).
Query Object.
How It Works.

When to Use It.
Further Reading.
Example: A Simple Query Object (Java).
Repository (by Edward Hieatt and Rob Mee).
How It Works.

When to Use It.
Further Reading.
Example: Finding a Person's Dependents (Java).
Example: Swapping Repository Strategies (Java).

14. Web Presentation Patterns.
Model View Controller.
How It Works.

When to Use It.
Page Controller.
How It Works.

When to Use It.
Example: Simple Display with a Servlet Controller and a JSP View (Java).
Example: Using a JSP as a Handler (Java).
Example: Page Handler with a Code Behind (C#).
Front Controller.
How It Works.

When to Use It.
Further Reading.
Example: Simple Display (Java).
Template View.
How It Works.

When to Use It.
Example: Using a JSP as a View with a Separate Controller (Java).
Example: ASP.NET Server Page (C#).
Transform View.
How It Works.

When to Use It.
Example: Simple Transform (Java).
Two Step View.
How It Works.

When to Use It.
Example: Two Stage XSLT (XSLT).
Example: JSP and Custom Tags (Java).
Application Controller.
How It Works.

When to Use It.
Further Reading.
Example: State Model Application Controller (Java).

15. Distribution Patterns.
Remote Facade.
How It Works.

When to Use It.
Example: Using a Java Session Bean as a Remote Facade (Java).
Example: Web Service (C#).
Data Transfer Object.
How It Works.

When to Use It.
Further Reading.
Example: Transferring Information about Albums (Java).
Example: Serializing Using XML (Java).

16. Offline Concurrency Patterns.
Optimistic Offline Lock (by David Rice).
How It Works.

When to Use It.
Example: Domain Layer with Data Mappers (165) (Java).
Pessimistic Offline Lock (by David Rice).
How It Works.

When to Use It.
Example: Simple Lock Manager (Java).
Coarse-Grained Lock (by David Rice and Matt Foemmel).
How It Works.

When to Use It.
Example: Shared Optimistic Offline Lock (416) (Java).
Example: Shared Pessimistic Offline Lock (426) (Java).
Example: Root Optimistic Offline Lock (416) (Java).
Implicit Lock (by David Rice).
How It Works.

When to Use It.
Example: Implicit Pessimistic Offline Lock (426) (Java).

17. Session State Patterns.
Client Session State.
How It Works.

When to Use It.
Server Session State.
How It Works.

When to Use It.
Database Session State.
How It Works.

When to Use It.

18. Base Patterns.
Gateway.
How It Works.

When to Use It.
Example: A Gateway to a Proprietary Messaging Service (Java).
Mapper.
How It Works.

When to Use It.
Layer Supertype.
How It Works.

When to Use It.
Example: Domain Object (Java).
Separated Interface.
How It Works.

When to Use It.
Registry.
How It Works.

When to Use It.
Example: A Singleton Registry (Java).
Example: Thread-Safe Registry (Java) (by Matt Foemmel and Martin Fowler).
Value Object.
How It Works.

When to Use It.
Money.
How It Works.

When to Use It.
Example: A Money Class (Java) (by Matt Foemmel and Martin Fowler).
Special Case.
How It Works.

When to Use It.
Further Reading.
Example: A Simple Null Object (C#).
Plugin (by David Rice and Matt Foemmel).
How It Works.

When to Use It.
Example: An Id Generator (Java).
Service Stub (by David Rice).
How It Works.

When to Use It.
Example: Sales Tax Service (Java).
Record Set.
How It Works.

When to Use It.
References

Index. 0321127420T10162002

Supplemental Materials

What is included with this book?

The New copy of this book will include any supplemental materials advertised. Please check the title of the book to determine if it should include any access cards, study guides, lab manuals, CDs, etc.

The Used, Rental and eBook copies of this book are not guaranteed to include any supplemental materials. Typically, only the book itself is included. This is true even if the title states it includes any access cards, study guides, lab manuals, CDs, etc.

Excerpts

In the spring of 1999 I flew to Chicago to consult on a project being done by ThoughtWorks, a small but rapidly growing application development company. The project was one of those ambitious enterprise application projects: a back-end leasing system. Essentially it deals with everything that happens to a lease after you've signed on the dotted line: sending out bills, handling someone upgrading one of the assets on the lease, chasing people who don't pay their bills on time, and figuring out what happens when someone returns the assets early. That doesn't sound too bad until you realize that leasing agreements are infinitely varied and horrendously complicated. The business "logic" rarely fits any logical pattern, because, after all, it's written by business people to capture business, where odd small variations can make all the difference in winning a deal. Each of those little victories adds yet more complexity to the system. That's the kind of thing that gets me excited: how to take all that complexity and come up with a system of objects that can make the problem more tractable. Indeed, I believe that the primary benefit of objects is in making complex logic tractable. Developing a goodDomain Model (116)for a complex business problem is difficult but wonderfully satisfying. Yet that's not the end of the problem. Our domain model had to be persisted to a database, and, like many projects, we were using a relational database. We also had to connect this model to a user interface, provide support to allow remote applications to use our software, and integrate our software with third-party packages. All of this on a new technology called J2EE, which nobody in the world had any real experience in using. Even though this technology was new, we did have the benefit of experience. I'd been doing this kind of thing for ages with C++, Smalltalk, and CORBA. Many of the ThoughtWorkers had a lot of experience with Forte. We already had the key architectural ideas in our heads, and we just had to figure out how to apply them to J2EE. Looking back on it three years later, the design is not perfect but it has stood the test of time pretty damn well. That's the kind of situation this book was written for. Over the years I've seen many enterprise application projects. These projects often contain similar design ideas that have proven effective in dealing with the inevitable complexity that enterprise applications possess. This book is a starting point to capture these design ideas as patterns. The book is organized in two parts, with the first part a set of narrative chapters on a number of important topics in the design of enterprise applications. These chapters introduce various problems in the architecture of enterprise applications and their solutions. However, they don't go into much detail on these solutions. The details of the solutions are in the second part, organized as patterns. These patterns are a reference, and I don't expect you to read them cover to cover. My intention is that you read the narrative chapters in Part 1 from start to finish to get a broad picture of what the book covers; then you dip into the patterns chapters of Part 2 as your interest and needs drive you. Thus, the book is a short narrative book and a longer reference book combined into one. This is a book on enterprise application design. Enterprise applications are about the display, manipulation, and storage of large amounts of often complex data and the support or automation of business processes with that data. Examples include reservation systems, financial systems, supply chain systems, and many others that run modern business. Enterprise applications have their own particular challenges and solutions, and they are different from embedded systems, control systems, telecoms, or desktop productivity software. Thus, if you work in these other fields, there's nothing really in this book for you (unless you wa

Rewards Program