| > And's it's NOT the kind of SQL that looks like SELECT <all-200-columns>
| FROM <table> WHERE <primarykey> = ? >of course. :-)
|
| So what should it look like ?
|
| Surley if you need to do a one of get of 200 columns this is the ONLY way
?
If you're building a user interface with 200 fields on it,
or a grid control with 200 columns, than sure.
However, in practice interaction with the "outside world"
of your application nearly always is best done through
some simpler set of information than *all* of them.
This might be through some XML message you send to a
remote system, or through a JSP page, or through a
thin-client JFC based applications. In all these
cases if you just need to show/manipulate a slice of
the data, in BC4J you just use the power of SQL to
select just the slice you need, while any changes
made through those views still get properly coordinated
with the underlying entities which encapsulate the
relevant business logic. Often the SQL has very complicated
WHERE clauses and joins in it to get the logical view
of the information just right.
The whitepaper outlines the basic way this works in the
framework.
________________________________________________________
Steve Muench, BC4J Development Team & XML Evangelist
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message -----
From: Shaun OHAGAN <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, October 01, 1999 9:39 AM
Subject: Re: Doubts about Entity beans, Should we use them?
===========================================================================
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".
