>> Richard said:
> I would argue that the Result Set interface is far more reusable and usable then
> an object graph or even an array of structures. The reason is simple, the
> ResultSet interface never changes across queries. No matter what data is
> captured the ResultSet interface remains the same. This makes it easier for
> developers to work with because they already understand the semantics of the
> interface (its always the same). In addition, it makes it easier for
> requirements to change because it fairly simple to introduce new columns of data
> or remove them. This require little effort on the client developer part and
> really no effort on the server side (you just change the query).
If we are just dealing with listing behavior, then if the changing requirements only
add or remove columns from a table in the client, then it probably is easier for
developers. But that is mostly because the changing requirements did not really
change the client.
OTOH, if the changing requirements necessitate more involved changes in the client,
then we are out of the scope of the argument for the ResultSet design as defined by
Richard (listing behavior).
Since I feel strongly both ways, I developed a hybrid solution I am using in my
current project. (With my luck I'll get the worst of both ;-)
I wrote a table data model to make using a collection of detail objects 'easier' on
the developers (as easy as looking for fields by names in a result set). It uses
reflection and follows the JavaBean (not EJB) convention of property names.
My server interface (stateless session beans) can generate collections of detail
objects (either directly from a JDBC query, or calling entity finders--the client
couldn't care less) and pass them back to the client. If the client only needs to
list them, then I drop a 'PropertyTablePanel' on my client frame and set the table
model to an instance of 'PropertyTableModel' built from the detail object class.
If the client needs to do something else that's fine too, the client has the detail
object (which could be anything including a value holder, state holder, proxy
object, etc.) with which to work.
Eventually, I'll write a 'CachedPropertyTableModel' or 'PagedPropertyTableModel' but
only when I need it (one of the tenets of eXtreme Programming, I believe).
For what it's worth, I will probably putting out the set of classes as open source
some time Real Soon Now.
Doug
--
Douglas W Sjoquist
[EMAIL PROTECTED]
http://www.sunetos.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".
