Using DAOs in Design


EJB design: Using DAOs in Design

  1. Using DAOs in Design (7 messages)

        I am designing an application for which I am thinking of designing the Data Access using the DAO Pattern.

         I have a few questions which if anyone could clarify, I would be grateful.

        1. DAOs are used so that the client is loosely coupled with the Persistence layer. So, say at a time, you can have only one type of DB at a time, say Oracle OR Sybase OR Sequel etc. So using Factory Pattern, we can create the corresponding DAO Object on the Fly.

            But, in my case, I have to talk to different types of DBs at a time. I mean, the DB which is solely to my new application will be one, say Oracle, but the application talks to a few other systems whose DB may be different.

            In such a situation, how DAOs can be effectively used? Anybody could help me in this..?

         2. Suppose I have various entities in my application domain , say Customer, Order..say a 10 different items.. So according to DAO pattern, I am going to have 10 different types of DAOs..? Is my understanding correct..?

          Expecting the replies asap...

    Thanks in Advance...

    Best Regards

    Threaded Messages (7)

  2. multiple daos[ Go to top ]

    I suggest you have a dao interface. Say CustomerDAO, Then have OracleCustomerDAO, MySQLCustomerDAO, etc. implement this interface. Then using the factory pattern, instantiate the dao's you need for your app.

  3. multiple daos[ Go to top ]

    Thanks a lot for ur reply.. But when implememting factory pattern, at a given point of time, I can have only one type of DAO.. either oracle or MySQL or etc.. which will be configured in some place.. (JNDI)

        But, suppose I need some entities to be read from one type of DB, some other entities from another type of DB, how can I do that..? Can we use multiple factories ?
  4. Use of a properties file might help[ Go to top ]

    In the property file you can define what implementation you need for which DAO
  5. Using DAOs in Design[ Go to top ]

    I might be inclined to make use of an O/R mapping layer, but I'm fond of them to begin with.

    If I read you right, you're going to have multiple entities. It's not uncommon to have one DAO per entity, no, although it doesn't have to be that many if you have good reasons to bring them together.

    I also gather that you're expecting to be interacting with multiple databases at once. Ignoring questions about things like XA and 2PC, I'm still not sure if you're expecting a single entity to come from more than one database, or different entities to reside in different databases.

    That is, are you expecting that Customer will reside in one database and, say, Order in another? That's fine - you could, for instance, have the factory configuration specify the database or the implementation based on the entity requested, or wire the implementations using dependency injection.

    If you're expecting a single entity, say, Customer, to reside in more than one database, then it's obviously not a simple as providing a single DAO implementation per entity, and you're into a slightly more complicated territory. In that case, I'd probably need to know more about the deciding factors for a particular datastore are.
  6. Using DAOs in Design[ Go to top ]

    Hi Geoffrey,

        Nice to see ur reply... Thanks a lot for spending time to analyze my problem.

        You have got it correctly. Say, Customer entity will always be coming from a given DB. and may be Order entity will be coming from a different given DB.

        Only thing is that the system talks to different types of DB at a given point of time. ie. If I implement a DAO pattern, and when I ask for Customer DAO, it should give me the implementation class corresponding to the DB I have configured,and similiarly for Order also.. So , in brief, at a time, I should be able to connect to different DBs(ofcourse for different entities).

       Now as per my understanding, a factory pattern will, in a given point of time, will provide me one implementation.. ie either Oracle or a 'X' DB imp.

        How can I imp the DAO pattern, so that When I need Customer DAO, I want,say,the Oracle Implementation, and when I need a Order DAO, a DB2 implementation..

    Expecting to hear from u...
  7. If you're still interested...[ Go to top ]

    Sadly, I failed to check up on this thread, so I missed your return query.

    In essence, if you have a factory of some kind creating DAO objects, that factory can supply a connection or datasource to the DAO upon DAO creation.

    The factory could then be configured on a DAO by DAO basis to supply one of several datasource based on the DAO being requested.

    For instance:
    public class Dao
      private Connection dbConnection;
      public Dao( Connection dbConnection ) { this.dbConnection = dbConnection; }
      // any other DAO superclass stuff

    public class CustomerDao
      public CustomerDao( Connection dbConnection ) { super( dbConnection ); }
      // rest of DAO

    On the factory side, you'd then use some kind of configuration (e.g. file, hard-coded configuration, script, whatever works best for you) to map from a class or dao name (however you make the factory/service locator request) to the DAO class and the appropriate data source.

    It's difficult to get much more detail without knowing a lot about how you'd implement the DAO and the factory, but this should start you off in the right direction.

    Of course, there are lots of other options here, ranging from accessing your DAOs from a more evolved service location pattern (Spring's IoC, Hivemind, etc.) to using an O/R mapping layer. Some O/R mapping layers may explicitly support multiple datasources, although I can't recall that as a feature in any that I've used.
  8. Using DAOs in Design[ Go to top ]


    Have you read this article?

    Core J2EE Patterns - Data Access Object

    I have using this pattern for a few years.
    I strongly recommend this pattern and article.

    Best Regards,