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".
