William,
I would like to address the circumstances under which the client requires a list
of data; data that is conceptually organized in a table format. This is not
intended to be take personally, it simply a response to your post.
In the case of listing behavior it makes sense to present lists of data as lists
and not graphs of domain objects. The reason is quite simple, you eliminate all
the overhead associated with accessing complex object graphs on the client. If,
for example, a client wants a list of all the employees and their current
salaries then that is exactly what should be delivered to the client. Send over
an array of detail objects or a serializable implementation of a ResultSet.
This is far easier for the client to work with then a complex graph of Employee
objects with lots of superfluous information (information not specific to my
current needs). Personally I like the use of serializable ResultSet object
because the the object manages the data and the list itself.
To say that a list of data, whether its an array of detail objects or a
serializable ResultSet, is not OO certainly seems indicative of a
misunderstanding of objects. Objects do not always represent business concepts,
in fact objects usally represent more utilitarian concepts like String, Socket,
and TextArea. The idea behind OO is two fold: (1) It provides simple unified
interface to data and behavior; (2) It provides more flexibility and
extensibility to systems. The first point is particularly important in this
case. OO representations of Lists are OO at its finest because these constructs
make it easier for programmers to work with the data.
Another point was made that its wasteful to convert information from objects to
lists. This seems like an odd point since the data is accessed (in most cases
involving lists) directly from the database which is usually relational. I
would say that its more wasteful to covert relational data into domain objects
just so that it can be presented in a tabular format on the client. This idea
that good OO requires all business data to be housed in business objects at
every tier is misguided. Data is data and If I want my data in a list then
that's how I should get it. If I need more complex behavior or relationships
then I'll model it as business objects with a complex graph. The point is, you
give the client what it wants - nothing more and nothing less. Don't force the
client applications to deal with graphs of domain objects simply because it
ideologically more conformable.
Enterprise JavaBeans provides an objectified view of the an enterprise system.
It allows us to model business concepts and provide a component model that can
assembled, reused, and re-assembled into new solutions while maintain
transaction and security control. In short it makes it simpler to assemble
solutions from existing components. While EJB, like MTS and CORBA is
objectified these are certainly not your father's objects. They are distributed
server side components and the paradigm that they live in is different from
traditional OO. Lets use good OO practices where appreciate but not at the
expense of performance and simplicity.
Richard
"Louth, William (Exchange)" wrote:
> Hi Sesh,
>
> Personally I do not believe in database-like view of the world that is
> constantly being advocated in list and tabular server operations. What you
> typically see is an collection of objects on the server side being
> transformed into an array x array of strings before transmitting to client.
> What happen to OO? I prefer to send my domain objects (State or Details
> objects, whatever you call them) to the client and rely on an good OOUI to
> solve the problem of mapping each object into what component it needs to be
> displayed in. I have an article coming up in JavaReport detailing how to
> better solve this great divide titled "Bridging the gap between Java Clients
> and Enterprise Java Beans using XML". To me OO concepts should be brought
> more and more into the design of client interfaces - please do not reply
> regarding widgets.
>
> kind regards
>
> William Louth
>
> > -----Original Message-----
> > From: Sesh Kumar Jalagam [SMTP:[EMAIL PROTECTED]]
> > Sent: Wednesday, April 26, 2000 6:28 PM
> > To: [EMAIL PROTECTED]
> > Subject: Cached Rowsets-do we need to use them
> >
> > Hai how is every one listing the data from the entitybeans. Does any one
> > use Cachedrowsets. I tried to use them but I was only able to use them
> > with BMP's . I couldn't find any way to convert an Enumeration to
> > CachedRowset.
> >
> > The method i am following to list the data to the users is by collection
> > of immutable objects (JavaBeans. with only getter fields).Are there any
> > other better ways to do this (
> > <http://www.ejbnow.com/ejbtips/ejbtip_4.html)>
> >
> > I want to know how others are doing this
> > Thank you
> > Sesh
>
> ***********************************************************************
> 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".
--
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".
