Quick Recap: Chapters 51 to 58

Let us quickly review whatever we learnt about Design Patterns in the previous few chapters

• A design pattern describes a proven solution to a recurring design problem, placing particular emphasis on the context and forces surrounding the problem, and the consequences and impact of the solution
• There are 5 design patterns in the SCWCD Exam:
     o Value Object Pattern
     o Data Access Object Pattern
     o Business Delegate Pattern
     o Model View Controller Pattern &
     o Front Controller Pattern
• The Value Object pattern provides the best way to exchange data across tiers or system boundaries, especially when there is network communication involved. This is a pattern that solves performance issues around network latency
• The DAO pattern provides the connection between the business logic tier and the resource (usually a database) tier. The Data Access Object represents a general interface to the resources layer: It handles all calls to it. JDBC is the most commonly used example of this
• The Business Delegate pattern reduces the dependency between tiers. It is an attempt to make tiers interchangeable so one can access or utilize the services of any other
• The Model-View-Controller architecture compartmentalizes the data and business logic (model) from the presentation (view) from the user action interpreter (controller).
• The Front Controller pattern presents one entry point to a Web site or service. It provides a centralized entry point that controls and manages Web request handling. It eliminates the dependency of the user on a direct resource.

The Key Terms we learnt in the previous few chapters are:

• Design Patterns
• Model-View-Controller
• Value Object
• Data Access Object
• Front Controller
• Business Delegate

Previous Chapter: Chapter 58 - Other Design Patterns

Next Chapter: Self Test - Chapters 51 to 58

Chapter 54: Data Access Object Pattern

In this chapter, we are going to take a detailed look at the DAO or Data Access Object Design Pattern.

What is Data Access Object Pattern?

The DAO pattern provides the connection between the business logic tier and the resource (usually a database) tier. The Data Access Object represents a general interface to the resources layer: It handles all calls to it. JDBC is the most commonly used example of this. Almost all J2EE Applications that access the database have a direct or indirect implementation of the DAO Pattern.

Is

This pattern is an object that encapsulates a set of behaviors for accessing databases, files, and other resources. This way you have only one API to deal with rather than a different one for every type of resource.

Is Not

This is not a pattern for a resource itself. Frankly speaking, this isn't a way to build a database or file manager.

Analogy

This is like using an ATM machine. The same interface will fetch the information requested from the back end, even though the bank changed database products the previous week.

Problem

Applications often need to use persistent data. This data persists in many forms such as files, relational databases, XML storage, and other types of repositories. All these stores have different APIs. Interfacing with so many APIs presents a problem when designing clients.

Responsibility

This pattern provides a uniform API to any persistent data storage.

Aim

This pattern attempts to consolidate the accessing of data from a complex source or set of sources to one object. This will reduce the network overhead by minimizing the number of network calls to get data, but the reduction of network traffic is not the main intention of this pattern.

Primary Activity

Getting and setting data from and to a permanent data source.

Context

Access methods to data vary between types of storage and vendor.

Benefits

Various parts of an application require access to persistent stores like databases and files. The APIs are inconsistent between types of stores and even between different vendors of the same type of storage. There needs to be a layer that has a uniform API to access these disparate data sources.

Usage

Any application that requires access to several data source types or even an application that accesses only one, but may switch in the future. The SQL is encapsulated in the method. That way if the SQL or datasource change, the layers above won't because the API remains constant.

Consequences

• Clients and components can now access data with the same API, which makes the variety of sources transparent and reduces complexity.
• This makes changing data sources easy and reduces errors.

Uses

At one level, JDBC uses an Abstract Factory technique to provide one API to many databases and types of files; the very essence of this pattern. However, the emphasis Sun places on this pattern is that of encapsulating the SQL so the implementation of actually querying the database is hidden from the next layer.

Other Related Patterns

Abstract Factory: Sun uses this factory for data access object strategy. They base it on the abstract factory method.

Previous Chapter: Chapter 53 - Value Object Pattern

Next Chapter: Chapter 55 - Business Delegate Pattern