JaiswalTraining

Get the online training



Corejava Servlet Jsp  Php  Hibernate  Ajax Web Service   Ejb2.1 Ejb3.0 Struts Struts2  JPA Spring Ibatis   JSF    JSF2.0  CoreJavaDesignPattern    Jquery  Flex J2EE-Design-Patterns  Jboss7  Maven  Contact Me                                                                                                                                                                        
            IGNOU SMU PTU Project                                           Training                                                                                                                              
              

Contact Us  0091- 9210721663         jaiswaltraining@gmail.com




Corejava
Servlet
Jsp
Php
Hibernate
Ajax
Web Service
Ejb2.1
Ejb3.0
Struts  
Struts2
JPA
Spring
Ibatis
JSF
JSF2.0
CoreJavaDesignPattern
Jquery
Flex
J2EE-Design-Patterns
Jboss7
Maven







Data Access Object
  • Context
    • Access to persistent storage, such as to a database, varies depending on
      the type of storage (relational databases, object-oriented databases, flat
      files, and so forth) and the vendor implementation.
Problem and Forces
  • Components such as bean-managed entity beans, session beans,
    servlets, and other objects uses appropriate APIs to achieve
    connectivity and manipulate the data source which introduces a tight
    coupling between the components and the data source
    implementation.
  • Persistent storage APIs vary depending on the product vendor.
  • Portability of the components is directly affected when specific
    access mechanisms and APIs are included in the components.
  • Components need to be transparent to the actual persistent store or
    data source implementation to provide easy migration to different
    vendor products, different storage types, and different data source
    types.
Solution
  • Use a Data Access Object (DAO) to abstract and encapsulate all access to
    the data source.
  • DAO manages the connection with the data source to obtain and store
    data..
The Data Access Object will be responsible for:
  •  Hiding the data source implementation details from its clients
  •  Exposing simple interfaces to business component.
Structure
  • Class diagram representing the Data Access Object  pattern



Strategies

  • Automatic DAO Code Generation Strategy
    • Since each BusinessObject corresponds to a specific DAO, it is
      possible to establish relationships between the BusinessObject, DAO,
      and underlying implementations (such as the tables in an RDBMS).
      Once the relationships are established, it is possible to write a simple
      application-specific code-generation utility that generates the code for
      all DAOs required by the application. The metadata to generate the
      DAO can come from a developer-defined descriptor file
  • Factory for Data Access Objects Strategy
    • The DAO pattern can be made highly flexible by adopting the
      Abstract Factory [GoF] and the Factory Method [GoF] patterns
Consequences
  • Access to persistence storage is transparent because the implementation
    details are hidden inside the DAO
  • Reduces Code Complexity in Business Objects
  • Enables Easier Migration
  • Adds Extra Layer
Related Patterns
  • Transfer Object
    • A DAO uses Transfer Objects to transport data to and from its clients.
  • Factory Method [GoF] and Abstract Factory [GoF]
    • The Factory for Data Access Objects Strategy uses the Factory Method
      pattern to implement the concrete factories and its products (DAOs). For
      added flexibility, the Abstract Factory pattern may be used.
  • Value List Handler
    • The Value List Handler is another pattern that provides lists of Transfer
      Objects constructed dynamically by accessing the persistent store at
      request time.