I'm thinking of a Data Access Object model, where either the EJB or JDBC
call would be inside a wrapper so the caller would have no idea where
the data is coming from. So the method signature for a select on a
primary key might look like
public static final RowSet accountSelect(int key)
This returns a RowSet as a "value object", but RowSets can be generated
on the fly, so the data could be retrieved from anyplace. If all the
data accesses are wrapped up this way, you can change form JDBC or EJB
or whatever, without the rest of the application being the wiser.
In the Core J2EE patterns book, there is even talk of DAO factories, the
idea being you might a DAO Oracle implementation or a DAO MySQL
implementation, and the application could be configured to call one one
day and the other the next.
I'm now using a Helper object between the Action and the DAO. The Action
selects the Helper, and passes it any necessary parameters, the Helper
selects the DAO, and catches the RowSet. The Helper is then inserted
into the context for access by the presentation layer. The Helper gives
you a place to put special output methods for the presentation layer (or
report layer, for that matter). Neither the Helper nor the DAO are
linked to HTTP or a Web application.
David Winterfeldt wrote:
>
> What DBMS design patterns were you thinking of? I was
> thinking that it would be nice if you could migrate
> from JDBC to EJB without having to change anything.
