[richard]
In addition, generic builders were made that could take any result set
and map it into a table. Builders were made that
generated HMTL tables as well as populating Swing tables. This allowed the
CORBA service interfaces to be reused for different client presentations
(HTML
for printing and GUI for perusing). This would not be possible with an
object
graph because the builders could not be generic; each builder would have to
know
the structure of the graph in advance.
[william]
This can be achieve by an _inspired_ engineer for object graphs. You just
have to apply
some form of abstraction. By the way IDE's have good builders which do not
require a
resultset interface. The resultset interface is the starting point but
please move on. Judging
by the latest issue of ACM Communications we are in for some radical changes
in human-computer
interaction. The problem I see is that we still have not even managed to
comprehend and affectively use the current standards.
There is no perfect solution but its always good to aim high and maybe with
some luck,
hard work and inspiration you achieve something which gets you and others
excited.
My intention is continue what I am trying to achieve across projects and
refine my solution.
William Louth
Inspired Consultancy
> -----Original Message-----
> From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 27, 2000 10:51 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cached Rowsets-do we need to use them
>
> Hi Aravind,
>
> Please see below ....
>
> Aravind Naidu wrote:
>
> >
> > Now, with the resultset method, I have the following points.
> > - If I was getting data from non-db sources, then I have to map it to a
> > resultset interface anyway, I might as well put it into a simple object
> > graph.
>
> The first time I used this technique was on a CORBA project that obtained
> data
> from IMS as well as JDBC. The implementation of ResultSet provided
> accessor
> methods that allowed us to merge data from these disparate sources into
> one
> ResultSet. The ResultSet interface hid the set methods making the object
> immutable to the client.
>
> Placing this same data into an object graph would not have made things
> simpler
> since the client developers needed to place the data into tables. The
> ResultSet
> interface was much better because the data was delivered in the same
> schema
> (tabular) that it was presented in. In addition, generic builders were
> made
> that could take any result set and map it into a table. Builders were
> made that
> generated HMTL tables as well as populating Swing tables. This allowed
> the
> CORBA service interfaces to be reused for different client presentations
> (HTML
> for printing and GUI for perusing). This would not be possible with an
> object
> graph because the builders could not be generic; each builder would have
> to know
> the structure of the graph in advance.
>
> >
> > - The signature of the business method then becomes largely meaningless.
> >
>
> The method name, its arguments, and its interface are very expressive.
> The
> method PayRoll.getEmployeeSalaries(int DepartmentID) is more then
> expressive
> enough.
>
> The one downfall of the the ResultSet is that a developer can not examine
> its
> interface to determine the type of data it contains. The developer must
> look at
> the documentation (we placed this information in the method comments ).
> Of
> source, the same is true of the detail objects since the developer must
> examine
> the JavaDoc or source code which is just another form of documentation.
>
> Richard
> --
> Richard Monson-Haefel
> Author of Enterprise JavaBeans, 2nd Edition
> Published by O'Reilly & Associates
> http://www.EjbNow.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".
***********************************************************************
Bear Stearns is not responsible for any recommendation, solicitation,
offer or agreement or any information about any transaction, customer
account or account activity contained in this communication.
***********************************************************************
===========================================================================
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".
