|
|
 | | From: | tpcunha | | Subject: | Better ways to implement DAOs | | Date: | 12 Jan 2005 17:36:51 -0800 |
|
|
 | Hi everybody,
Please, i'd like some tips for implementing a good-quality DAO.
For example, is this structure good?:
MyTableDAO [interface]
DBMyTableDAO [implementation]
MyTableDAOFactory [singleton]
All queries (insert, delete, update, select) are defined in
DBMyTableDAO. And the initialization of Collections of DTOs (for a
select that return a resultSet with more than one record) and single
DTOs (for searchs using the primary key, for example). This makes the
code quite confusing, also because of try-catch blocks.
Are there better ways to make DAOs?
Thanks.
|
|
| | From: | t_p_c | | Subject: | Re: Better ways to implement DAOs | | Date: | 13 Jan 2005 13:06:30 -0800 |
|
|
| thanks kirkk... these code samples will be helpful...
the confusion was mostly because of too much code in the same
classes...
i will try (following the samples i got from kirkk) to divide my dao in
other classes...
i think this will decrease the disorganization.....
thanks.
|
|
| | From: | Mark Nicholls | | Subject: | Re: Better ways to implement DAOs | | Date: | Thu, 13 Jan 2005 11:33:36 -0000 |
|
|
|
"tpcunha" wrote in message
news:1105580211.142905.28890@z14g2000cwz.googlegroups.com...
> Hi everybody,
> Please, i'd like some tips for implementing a good-quality DAO.
> For example, is this structure good?:
>
> MyTableDAO [interface]
> DBMyTableDAO [implementation]
> MyTableDAOFactory [singleton]
>
> All queries (insert, delete, update, select) are defined in
> DBMyTableDAO. And the initialization of Collections of DTOs (for a
> select that return a resultSet with more than one record) and single
> DTOs (for searchs using the primary key, for example). This makes the
> code quite confusing, also because of try-catch blocks.
> Are there better ways to make DAOs?
>
> Thanks.
Sounds like a 'table gateway' (fowler).
seems sensible...I'm doing one right now.
I don't see what would be confusing, and what the problem with try catch is.
If your in MS world then table gateway fits nicely with the MS dataset world
(see MS application blocks to rid yourself of dispose drama/nightmare).
If you in another world, then see 'domain model' as an alternative.
(there's also something called a 'record gateway').
|
|
| | From: | kirkk | | Subject: | Re: Better ways to implement DAOs | | Date: | 13 Jan 2005 06:43:55 -0800 |
|
|
| Take a look at some of the code samples at www.kirkk.com. Scroll down
on the home page and download the GOF Patterns Code Samples. You'll
find numerous examples (starting simple to more complex and flexible)
of how to design a flexible data access mechanism. To run the code,
you'll need a MySQL installed, but simply reading the code should offer
some useful suggestions.
The general idea is that you really only need a single DAO in your
application. The DAO can be configured with a Command object that
encapsulates the SQL statement you want to execute. That's the simplest
case and can be accomplished with a couple of classes. Additional
sample code builds on this idea.
Keep in mind these are just samples, and not suitable for production
quality applications without some important modifications.
Kirk Knoernschild
www.kirkk.com
www.extensiblejava.com
tpcunha wrote:
> Hi everybody,
> Please, i'd like some tips for implementing a good-quality DAO.
> For example, is this structure good?:
>
> MyTableDAO [interface]
> DBMyTableDAO [implementation]
> MyTableDAOFactory [singleton]
>
> All queries (insert, delete, update, select) are defined in
> DBMyTableDAO. And the initialization of Collections of DTOs (for a
> select that return a resultSet with more than one record) and single
> DTOs (for searchs using the primary key, for example). This makes the
> code quite confusing, also because of try-catch blocks.
> Are there better ways to make DAOs?
>
> Thanks.
|
|
|
