• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

DAO doubts

 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dear All,

I have read the DAO pattern on Sun website. http://java.sun.com/blueprints/patterns/. I found that its example is refer to the SAME business method having mulitple datasources.

Below is my understanding (correct me if wrong):

Shopper info (As a Transfer Object ShopperTO) can be come from either a MySQL datasource or Oracle datasource. So, I will write 2 concrete DAO classes, one for MySQL and one for Oracle.



To allow the database change runtime, I write 2 DAOFactories:





My conern:
1. Is my concept correct regarding the use of DAO ?
2. If I have other biz method that ONLY existed in MySQL instead of Oracle, how to implement it ?
i.e;
//biz method only occur in MySQL
otherShopperMethod();

Do I need to add this in the abstract DAOFactory ? If yes, The OracleDAOFactory has to implement this even this method is always empty (this seems wrong).

3. Actually, I am designing a system with persistance storage, it is probably the data source will not be changed from the same biz logic. i.e. we always use MySQL storing the shopper info. However, we have to get other information from an Oracle database. In this case, there are 2 datasources serving 2 different business logic separately. Is the DAO pattern still apply there ? Could anyone suggest how to do this ?

Thanks
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Vince Hon:
1. Is my concept correct regarding the use of DAO ?



I think so.


2. If I have other biz method that ONLY existed in MySQL instead of Oracle, how to implement it ?



The purpose of the DAO pattern is to allow clients to not care about where the data is coming from. So you first need to decide how you expect the system to behave when it accesses a datasource that doesn't support a specific operation.


3. Actually, I am designing a system with persistance storage, it is probably the data source will not be changed from the same biz logic. i.e. we always use MySQL storing the shopper info. However, we have to get other information from an Oracle database. In this case, there are 2 datasources serving 2 different business logic separately. Is the DAO pattern still apply there ? Could anyone suggest how to do this ?



You should have two different types of DAOs then - one ShopperInfoDAO, and one for the other business logic. Your ShopperInfoDAO would currently only have a MySQL implementation.

The reason for still using the DAO pattern would be to make the code more testable (you can write unit tests that don't access a database at all by providing mock-DAOs to the code under test) and to allow later to change to a different persistence store, without having to change a lot of code.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Encapsulation is a design issue that deals with how functionality is compartmentalized within a system. You should not have to know how something is implemented to be able to use it. The implication of encapsulation is that you can build anything anyway you want, and then you can later change the implementation and it will not affect other components within the system (as long as the interface to that component did not change). People often say that encapsulation is the act of painting the box black � you are defining how something is going to be done, but you are not telling the rest of the world how you�re going to do it. For example, consider your bank. How do they keep track of your account information, on a mainframe, a mini, or a PC? What database do they use? What operating system? It doesn�t matter to you because the bank has encapsulated the way in which they perform account services. You just walk up to a teller and perform whatever transactions you wish.

In Encapsulating Database Access I describe the concept of a database encapsulation layer, various encapsulation architectures, and implementation strategies (one of which is DAOs) for database encapsulation.

- Scott
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Vince Hon:


My conern:
1. Is my concept correct regarding the use of DAO ?
2. If I have other biz method that ONLY existed in MySQL instead of Oracle, how to implement it ?
i.e;
//biz method only occur in MySQL
otherShopperMethod();

Do I need to add this in the abstract DAOFactory ? If yes, The OracleDAOFactory has to implement this even this method is always empty (this seems wrong).

3. Actually, I am designing a system with persistance storage, it is probably the data source will not be changed from the same biz logic. i.e. we always use MySQL storing the shopper info. However, we have to get other information from an Oracle database. In this case, there are 2 datasources serving 2 different business logic separately. Is the DAO pattern still apply there ? Could anyone suggest how to do this ?

Thanks



DAO pattern is actually one of the way to implement the Layers Architecture. The main purpose is to isolate the data access
code to a separate tier called the Integration Tier.

#1. Good start. You have grasped the concept explained in the example.
#2. Business logic should be agnostic to the persistance mechanism. If you have to define some business logic that is
not applicable to another database then your design is wrong. Analyze the requirements and find out what varies and
encapsulate it behind a well defined interface.
#3. You have to design your own persitance layer for your requirements.
This layer will have a Mediator that will encapsulate the rules required to dynamically switch between the two different databases during runtime.
There is no better resource to learn how to
design a persistance layer than Scott Ambler. I suggest you start from his website.
[ June 17, 2005: Message edited by: bparanj ]
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic