Chris Raber wrote:
> 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.
Quite right.
However, I find myself agreeing in principle with Mr. Louth, actually,
but for reasons that I don't think have been brought up yet.
In my mind, there is a happy medium somewhere between delivering the
client exactly what it needs--no more and no less--and delivering the
client "a lot of extra stuff", as you put it. That happy medium's
content is governed by factors which haven't been taken into account in
this discussion yet--system change, number and types of different
clients, and who's responsible for which parts.
Frequently, in a really big system, the folks writing the "server
stuff"--the Enterprise Beans, the servers, the loaders, etc.--are
different from the folks writing the "client stuff"--the servlets, or
the custom GUI, or various timer-based job schedulers, etc. They're
also frequently on different schedules after the initial release.
Oftentimes, you want to provide desired functionality on the server side
(can you tell which camp I'm in) once, non-redundantly and as lazily as
possible, and let the various clients sort it out amongst themselves as
to what bits of the information you return are useful. If you can--up
front, ahead of time--figure out an object to return that can be "filled
up" later, then you've been a good lazy architect and developer
(laziness is a virtue) because now when the client's requirements change
or if a new client comes on line you've hopefully already locked down at
least the interface both clients will be expecting, even if the data
*behind* the interface is "thinner" in one client's case than in the
other's.
I take Mr. Louth's icon argument, while a bit stretched, to be a good
example of this--I fully subscribe to its spirit, if not its letter.
:-) That is, the web client may not care about anything more than the
"raw" data--the list coming back from the server may be represented
simply as two strings: name and salary, let's say. But the GUI client
that Mr. Boss wants online in the usual
management-inspired-and-utterly-impossible two weeks may need to show
additional information that is not currently in that list (name, salary,
description, age, gender). In my mind, the server should be responsible
for sending back objects that follow the Proxy design pattern that
contain within them information that is Very Likely (whatever that
means) to be used, and that delegate back to the server for information
that is Not Very Likely to be used. For example, an EmployeeProxy, a
subclass of Employee, should have local by-value copies of, say, name,
ID and, oh, let's say age. Its other method implementations should
delegate, in good Proxy fashion, back to the, say, EJB container.
Figuring out what Very Likely and Not Very Likely are is art; that's
what makes this job fun.
Now you can take this too far, which the Proxy pattern doesn't really
address--you can decide that *all* the information that could be
represented is critically important, and so should be contained by value
in the Proxy object itself, and suddenly your Proxy object looks
surprisingly like the real thing. That's bad.
Following the Proxy pattern instead of the serialized ResultSet
"pattern" also lends additional benefits, which is the ability (at least
in theory) to fix performance without modifying the client or the
server, but modifying only the Proxy object. Different proxy subclasses
can be returned based on the capabilities of the client: if the client
can indicate somehow in its initial request that it's interested in
certain fields, then a Proxy could be built to precache those fields in
itself, preventing unnecessary delegation.
Finally, though, if you're writing the client and the server, and there
will never be another kind of client (who can predict *that*, IMHO?),
then I pretty much subscribe to the ResultSet view of the world espoused
by Mr. Monson-Haefel--in that case you really *do* know exactly what
must be delivered, and moreover you know that that requirement will
never change. In my experience this happens so rarely as to be largely
inapplicable, but I suppose the point still stands.
Cheers,
Laird
===========================================================================
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".
