RE: DAO and Struts Best Practice

[Phase Web and Multimedia]

Thanks much. That's some excellent feedback.

Brandon Goodin
Phase Web and Multimedia
P (406) 862-2245
F (406) 862-0354
[EMAIL PROTECTED]
http://www.phase.ws


-----Original Message-----
From: Jacob Hookom [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 17, 2003 10:31 AM
To: 'Struts Users Mailing List'
Subject: RE: DAO and Struts Best Practice


So when you are describing objects that receive parameters, you are
looking along the lines of a transaction?  If so, you usually want to
interface out the transaction object so you can possibly change the
language later-- take a look at OJB for example.  They have the base
persistence broker layer which works with queries at the object/method
level.  Then, OJB provides another overhead layer you can opt to use
that provides JDO where queries are done like SQL statements, but with
EL-like markup.

Usually I treat DAO's from the socialist standpoint.  Meaning, you have
a few big classes, then a bunch of tiny ones that are just state beans
(your row gateways).

Persistence is taken care of by one of the big classes that knows how
each bean is mapped/handled.  The big class also takes in Query objects
that internally, will spit out SQL code based on the big class's
mappings -- I think the pattern may be Strategy/Visitor.

public List selectAll(Query query) throws DAOException
{
        // have the query build sql based on my mappings
        String sqlCode = query.buildSql(this.getSchemaDescriptor());

        List results = new LinkedList();
        Connection conn = null;
        try
        {
                conn = this.getConnection();
                .....
        }
        catch (SQLException e) {....}
        finally { conn.close(); }

        return results;
}

If your schema is complex enough that you want to do additional checking
before querying, you may want to write an additional step where the
query outputs a set of criteria or an descriptor object that you can do
validation on, instead of letting the query object go hog-wild and
create it's own SQL code.  So the above example becomes:

QueryDescriptor qDesc =
        query.getQueryDescriptor(this.getSchemaDescriptor());

if (this.validateQueryDescriptor(qDesc))
{
        .....
}

Also, I noticed that you brought up Connections in your description; I
wouldn't advise giving your "beans" any connections.  Really, your beans
should know nothing of persistence or SQL, which should all be taken
care of by a 3rd party class.

-Jacob Hookom



--
To unsubscribe, e-mail:
<mailto:[EMAIL PROTECTED]>
For additional commands, e-mail:
<mailto:[EMAIL PROTECTED]>



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>