Scribd
Upload
52 views

Data Access Object

The data access object (DAO) pattern provides an abstract interface to the database. The DAO acts as an intermediary between the domain model and data source. It encapsulates all data access logic and hides the details of the database from the client. This isolation separates the concerns of application access needs from data access implementation and allows switching data sources without affecting clients.

Uploaded by

Burak Basaran
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
52 views

Data Access Object

The data access object (DAO) pattern provides an abstract interface to the database. The DAO acts as an intermediary between the domain model and data source. It encapsulates all data access logic and hides the details of the database from the client. This isolation separates the concerns of application access needs from data access implementation and allows switching data sources without affecting clients.

Uploaded by

Burak Basaran
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 12

Data access object

Data access object

• In computer software, a data access object (DAO) is an object


that provides an abstract interface to some type of database
or persistence mechanism, providing some specific operations
without exposing details of the database
• It provides a mapping from application calls to the persistence
layer
• This isolation separates the concerns of what data accesses
the application needs, in terms of domain-specific objects and
data types
• The DAO implements the access mechanism
required to work with the data source
• The data source could be a persistent store
like an RDBMS, an external service like a B2B
exchange, a repository like an LDAP database
• The DAO completely hides the data source
implementation details from its clients
The class diagram representing the relationships
for the DAO pattern
Sequence Diagram
• BusinessObject
– The BusinessObject represents the data client. It is the object that requires access to
the data source to obtain and store data..
• DataAccessObject
– The DataAccessObject is the primary object of this pattern. The DataAccessObject
abstracts the underlying data access implementation for the BusinessObject to enable
transparent access to the data source. The BusinessObject also delegates data load
and store operations to the DataAccessObject.
• DataSource
– This represents a data source implementation. A data source could be a database such
as an RDBMS, OODBMS, XML repository, flat file system, and so forth.
• TransferObject
– This represents a Transfer Object used as a data carrier. The DataAccessObject may use
a Transfer Object to return data to the client. The DataAccessObject may also receive
the data from the client in a Transfer Object to update the data in the data source.
Implementing Data Access Object pattern
Creating data object class

public class Role extends BasicData {


private String name;
private String exp;

public String getExp() {


return exp;
}
public void setExp(String exp) {
this.exp= exp;
}
public String getName() {
return name;
}
public void setName(String name) {this.name = name;}
}
Implementing Data Access Object pattern
Mapping data object to the database table

• hibernate-mapping default-lazy="false">
•
• <class name=«Project.UsersRole" table="L_ROLE" >
• <id name="id" type="long" column="ID" >
• <generator class="org.hibernate.id.TableHiLoGenerator">
• <param name="table">IKM_SEQ</param>
• <param name="column">SEQUENCE_NO</param>
• <param name="max_lo">0</param>
• </generator>
• </id>
• <property name="name" type="string" column="NAME" length="60" not-null="true"/>
• <property name="exp" type="string" column=«EXPLANATION" length="255"/>
• </class>
• </hibernate-mapping>
Implementing Data Access Object pattern
Searching for a particular role name

• Criteria criteria;

• criteria = session.createCriteria(Role.class);
• if (role.getName() != null && rol.getName().length() != 0)
• criteria.add(Restrictions.ilike("name",
• "%" + rol.getName() + "%"));
• criteria.addOrder(Order.asc("name"));
• results = criteria.list();
Results
• Enables Transparency
– Business objects can use the data source without knowing the specific
details of the data source's implementation. Access is transparent because
the implementation details are hidden inside the DAO.
• Enables Easier Migration
– A layer of DAOs makes it easier for an application to migrate to a different
database implementation. The business objects have no knowledge of the
underlying data implementation. Thus, the migration involves changes
only to the DAO layer.
• Reduces Code Complexity in Business Objects
– Because the DAOs manage all the data access complexities, it simplifies
the code in the business objects and other data clients that use the DAOs.
All implementation-related code (such as SQL statements) is contained in
the DAO and not in the business object. This improves code readability
and development productivity.
Results
• Centralizes All Data Access into a Separate Layer
– Because all data access operations are now delegated to the DAOs, the separate data access layer can be
viewed as the layer that can isolate the rest of the application from the data access implementation. This
centralization makes the application easier to maintain and manage.
• Not Useful for Container-Managed Persistence
– Because the EJB container manages entity beans with container-managed persistence (CMP), the container
automatically services all persistent storage access. Applications using container-managed entity beans do
not need a DAO layer, since the application server transparently provides this functionality. However, DAOs
are still useful when a combination of CMP (for entity beans) and BMP (for session beans, servlets) is
required.
• Adds Extra Layer
– The DAOs create an additional layer of objects between the data client and the data source that need to be
designed and implemented to leverage the benefits of this pattern. But the benefit realized by choosing
this approach pays off for the additional effort.
• Needs Class Hierarchy Design
– When using a factory strategy, the hierarchy of concrete factories and the hierarchy of concrete products
produced by the factories need to be designed and implemented. This additional effort needs to be
considered if there is sufficient justification warranting such flexibility. This increases the complexity of the
design.
Referances
• http://
java.sun.com/blueprints/corej2eepatterns/Pa
tterns/DataAccessObject.html
• http://
en.wikipedia.org/wiki/Data_access_object
• http://en.wikipedia.org/wiki/Object-
relational_mapping

You might also like