I use my own framework because I don't know any better.
I am using Torque as my underlying persistence mechanism, and I have
introduced a very simple level of indirection that I think should keep me
independent of Torque in the future (I plan to swap in Hibernate or OJB on
the next app I work on). The level of indirection I introduced is
encapsulated in an object I call the DaoManager. The DaoManager is created
by a Factory class that gives me an instance of the DaoManager that works
for my particular application. Right now my Factory is creating a
DaoManager that works with Torque, but in the future it will create one that
works with Hibernate or OJB. (More info on the Factory pattern is in the
Gang of Four book, not the J2EE core patterns book someone recommended to
Sasha earlier today).
public interface IRecordDao {
public BigDecimal getId();
public void setId(BigDecimal id);
}
public abstract class DaoManager {
public abstract IRecordDao createDao(Connection conn, String daoClassName)
throws DaoException;
public abstract IRecordDao getDao(Connection conn, String daoClassName,
BigDecimal id)
throws DaoException;
public abstract void saveDao(Connection conn, IRecordDao record)
throws DaoException;
public abstract void removeDao(Connection conn, String daoClassName,
BigDecimal id)
throws DaoException;
}
As you may have noticed, this technique introduces the constraint that each
DAO must have a single numeric primary key. This is not an onerous
constraint, but may be an issue in an existing database where introducing
surrogate keys would cause problems.
I am interested in this topic so I may do some research this weekend to see
if I can think of a better way than I am currently using.
I don't know if there's a better list to discuss this type of thing... so
far this seems to be a pretty good one :) You might want to prefix your
messages with [OT] (off-topic) if you aren't sure if they are appropriate
for the list.
Matt
----- Original Message -----
From: "Sasha Borodin" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Friday, October 10, 2003 6:44 PM
Subject: Keeping Actions clean - separating actions from business modelfrom
persistence
> Ted, Matt, Joe, and all the other helpful folks that chimed in earlier on
> persistence mechanisms:
>
> In trying to keep with best practices, I've managed to remove all "model"
> related code (business logic, and persistence) out of the Actions'
execute()
> method. Now I'd like to take it one step further and decouple the
business
> model classes from the implementing persistence technology (btw, settled
on
> OJB for now :). From Joe's post, it seems like the DAO pattern is called
> for to accomplish this.
>
> My (slightly off topic) question is this: who develops their own DAO
> framework (like the dao and dao factory interfaces), and who uses a 3rd
> party framework (like iBATIS's Database Layer) and why? There was
something
> mentioned about the discovery of the persistence mechanism as well...
>
> Any references to webpages/books would be appreciated.
>
> BTW, I've been shamelessly posting to this list questions that are
probably
> better directed elsewhere. What would be a more appropriate list?
>
> Thank you,
>
> -Sasha
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
