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