DAO pattern RRS feed

  • Question

  • Hi All,

    I have a question related to the DAO pattern

    I have seen a project in which , we had a single factory for the whole database and helper classes for supported databases.

    I think that would be better pattern to address transaction and connection problem compared to DAO in which we have single factory for each table.

    Can you please guide me what prompts us to have factories for each table rather than for whole application.

    What are advantages and disadvantages in these two approches

    Please provide me with your comments

    Wednesday, September 13, 2006 12:25 PM

All replies

  • We use a single component to access the database for all of our applications. It is fashioned after the old Data Access Blocks available from the Microsoft site. We find it very useful because we never have to write code to create a DataSet/DataTable/DataReader ever again. We just call this component.
    Thursday, September 14, 2006 7:29 PM
  • Hi DeborahK,

    Yes, i am asking about the same pattern's advantages and disadvantages over DAO pattern in which we create one factory for one table.

    If somebody can throw light on this,  that would be very nice of him/her.



    Friday, September 15, 2006 5:38 AM
  • Hi qsnet,

       with your permission, as I see it, you are trying to compare apples with oranges

       Deborah's frameworks will help you in not to worry about internal details when accessing specific databases

       Data Access Objects (DAOs) enable your business layer store and retrieve domain objects without worrying about how database schema is organized (RDBMS? XML? Web Services? A mix of everything?)

       So, you can still decide implementing a Customer DAO, using Deborah's framework in an inner level

       Please check figure 2.12 in an oldy but goldy Patterns and Practices book: Application Architecture for .NET: Designing Applications and Services (Chapter 2, Designing the Components of an Application or Service)

       There you have two kinds of data-access components:

    1. Data Access Logic Components (the DAO's, in other words)
    2. Data Access Helpers

       I will reproduce book's words:

    1. Data access logic components expose methods for inserting, deleting, updating, and retrieving data. This includes the provision of paging functionality when retrieving large quantities of data.
    2. You can use a data access helper component to centralize connection management and all code that deals with a specific data source.


       Not sure whether I'm clear explaining that both are complimentary strategies to address different problems, not alternate ways to face a same one issue

    Saturday, September 16, 2006 5:08 AM