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.
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.
This is not a pattern for a resource itself. Frankly speaking, this isn't a way to build a database or file manager.
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.
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.
This pattern provides a uniform API to any persistent data storage.
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.
Getting and setting data from and to a permanent data source.
Access methods to data vary between types of storage and vendor.
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.
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.
• 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.
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
© 2013 by www.inheritingjava.blogspot.com. All rights reserved. No part of this blog or its contents may be reproduced or transmitted in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without prior written permission of the Author.