I wrote a Session Bean that directly retrieved
data from a DB using DataSource (obtained via JNDI code).
If I want to use a DAO to separate the Session Bean
from the DB can I put JNDI code, to get DataSource,
into the DAO ?
DAO can have a method that return, to the Session Bean,
the Data Transfer Object that Session Bean will
send to the client ? (the alternative is that Session
Bean builds the DTO, after having called many DAO's methods).
Many thanks in advance,
- RE: Two DAO questions by Ruslan Zenin on February 23 2004 22:10 EST
- Two DAO questions by Andy Grove on February 25 2004 08:13 EST
I guess it all depends what you want to do with your DAO.
For example, you can create a DAO factory class that creates and manages instances of your DAOs. This DAO factory could be configurable (e.g. what is the name of DATA SOURCE to use)
Then since DAO already have mapping to the relational data e.g. ValueObjects
I'm not sure if you need to have on top of that Session bean that does it again...wraps all the stuff into Transfer Object for remote access.
May be it will work better for you to have:
DAO factory that used be your application code to obtain DAO instance:
MyDAOFactory f = MyDAOFactory.getInstance();
MySampleDAO myDao = f.getMySampleDAO();
Then by hiding implementation of actual DAO, you can have different implementations (IN-MEMORY, JDBC, JDO, EJB...)
Typically the DAO would be responsible for constructing the DTO.
Take a look here for some sample DAO code:
Thank you (Ruslan and Andy)
Andy, I saw the example.
In DAO constructor you receive a Connection object.
Is it correct that Session Bean passes the Connection
to the DAO ?
I put all SQL code (getConnection() included) in DAO
but I'm not sure that this is a good approach ????
On the other way, if I put getConnection() inside
Session Bean I don't completely divide the Bean itself
from the below DataSource.
Can you suggest me the better approach ?
It is best to keep connection code separate from your DAO implementation code (you may want to change the way you obtain connections later or may want to start using container-managed transactions).
I tend to use the approach of passing a Connection or some sort of Connection factory class into the DAO constructor.
I'd recommend downloading the evaluation copy of FireStorm - you can use this to generate fully working DAO code for up to 5 tables (great for learning how to use DAO). It supports JDBC, EJB, and JDO.
You can download it from:
Hi, It is recommended that you pass the connection object from the deployment tier to tiers like data access tier. Your DAOs should be testable regardless of how you want to get the connection. For more information please see the excellent book of Derek C. Ashmore : J2EEArchitectsHandbook. You can download that book from this site. Cheers, Reza