DAO Pattern v/s Generic DAO Approach

Discussions

EJB programming & troubleshooting: DAO Pattern v/s Generic DAO Approach

  1. DAO Pattern v/s Generic DAO Approach (1 messages)

    I need some expert advice in deciding which Data Access strategy is better for my current J2EE project.

    I have two options in hand:

    1) To use generic DAO object. This component will encapsulate JDBC calls and provide common methods like executeSQL(), executeSP() etc. All business components will call this generic DAO to access database. To provide generic interface this component will exchange information using Map or List style objects. Business object will pass the SQL statement of the name of the stored procedure to the DAO for execution.

    2) Second option is to follow classic DAO pattern and have almost one DAO behind every business component. Keep DAO interfaces/factory and similar stuff. Business objects and DAO can exchange information using specific value objects which I think will perform much better than Map or List type objects. This involves writing lot of DAO classes over just 1 generic DAO component.

    Does anyone have any experience w.r.t performance, implementation, flexibility around this?
  2. DAO Pattern v/s Generic DAO Approach[ Go to top ]

    Helo,

    if your problem entity structure changes a lot, do the first one may save your problem.

    if you have time, do the second option.

    if the database has been built before, beware that there maybe some *dark* area where the data entity may not make sense, or will not fit into your second option, then i suggested you to use option 1.

    hope this help..
    -ljb.