The pattern that I use is very similar. I would call your "Home" interface
a Registry. The Registry defines all the CRUD operations. You'd create a
Registry for every important object. For example, CustomerRegistry would be
a collection of all Customer objects. The impl class contains the logic to
perform the appropriate CRUD operations. Amongst the advantage that I see
is that it decoupling persistence from the DOM, allows me to make my
persistence scheme plugable.
Kirk
----- Original Message -----
From: "Eric Williams" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, March 15, 2001 4:36 AM
Subject: Re: SQL Everywhere?
> On our project, we are using a hybrid of direct SQL and a homegrown
> object/relational mapping tool. But we certainly don't scatter SQL
> everywhere. We keep the SQL isolated, wrapped behind an interface.
>
> Specifically, we develop *Home interfaces (regular interfaces, not EJB
home
> interfaces) for each table or group of related tables. The *Home interface
> defines methods for accessing the data (e.g., create(), update(),
> findBy*()). Then we create an implementation class that performs the
> database access using our O/R toolkit and/or SQL. All of our database
access
> is limited to these classes.
>
> Sometimes, we have to pass search criteria objects from the EJB client to
> the server to define the criteria for the search. These are never SQL
> expressions, but are usually name / value pairs... or custom criteria
> classes that are specific to the situation. The *Home implementation class
> uses the criteria to build the query WHERE clause.
>
>
> -eric
>
> ----- Original Message -----
> From: "John Harby" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Wednesday, March 14, 2001 1:23 PM
> Subject: SQL Everywhere?
>
>
> > This is sort of a design question for EJB applications in general. In
the
> > database aspect of the app, I have seen different ways of managing the
> SQL.
> > One way is the "ScatterSQLEverywhere" anti-pattern which is where SQL
> > strings are found in any subsystem/tier (although maybe a single db
> > subsystem is executing the queries). These are a mess but usually cater
to
> > performance requirements which is why some are still around.
> >
> > Another is where one defines an "object-based" SQL interface and uses
this
> > as a facade to the database. E.G., I have a Column class and a Table
class
> > and a Query class that contains columns and tables. This has some nice
> > aspects aesthetically but tends to look like a Little Language pattern
and
> > must undergo continual maintenance. For example if my DBFacade subsystem
> > supports statements such as "SELECT x FROM Table WHERE y=?" and then
your
> > requirements mandate that you need SQL such as "SELECT x FROM Table
WHERE
> y
> > IN (SELECT ... FROM ... WHERE ...)" you will need to enhance this facade
> to
> > support such queries. Since SQL is Turing complete I believe, this
Little
> > Language could evolve into something isomorphic to a Big Language - this
> is
> > visible in all the CMP limitations. Are there any better ways to handle
> SQL
> > for BMP, various session beans and whatever else may be required in a
J2EE
> > application?
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at http://explorer.msn.com
> >
> >
>
===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> >
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
