To Neil, Chris, and Richard,
I have to side with William on this one. Maybe it's because he quotes Tog so often :-)
Let us not forget that we are building components. What good are components with out
reusability? I summit that to return a finely tuned row set of primitive types
predetermines the user interface. Maybe it's more accurate to say that the returned
data was determined from the final user interface.
With such high coupling between the UI and server component, reusability is severely
compromised.
So you send some extra data over the wire? What wire? The one between the app server
and webserver, or between app server and LAN clients? We have found that in either
case, network through put is not the bottle neck.
We have been able to use obect methods that summarize, translate or concatenate the
detail data to great benefit. The same "customer" object graph can be used for
detailed listings and simple name, primary phone listings. That's a big win for
reusability. The extra hundred bytes pre customer is not a
problem because the lists are necessarily short. As William said, if you're returning
too much data, your UI needs an overhaul.
Victor Langelo
Eclipse Services
Neil Thorne wrote:
> This argument does not hold much strength. I am a GUI designer and you would
> load up all icons you might be asked to use in one batch (or subsequent
> updates if necessary). You could identify each icon as a *String* that is
> passed over. You should be able to recreate state from a small amount of
> information as possible (bandwidth protectors kept happy).
>
Chris Raber wrote:
> Hey I dig objects too, why do you think I work for GemStone?
>
> However the problem is that without a "value holder" approach you end up
> serializing a lot of extra stuff to the client. Depending on the scale of
> things this can be a performance and scalability crusher. "Good OO" has to
> be balanced with pragmatism when the distributed nature of these
> environments is taken into consideration.
>
> When the "network really Is the computer" this may change. But we ain't
> there yet! Are the bandwidth guys listening? ;-)
>
> Regards,
>
> -Chris.
Richard Monson-Haefel wrote:
> 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
===========================================================================
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".
