[richard]
I would argue that the ResultSet 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).
[william]
Richard, I have already created a solution that far outstrips the ResultSet
interface in
terms of reusability. The application I recently showcased on this list was
created
using my solution which in my opinion is immensely powerful. The framework
is so powerful
that the browser window shown in the screenshot was built with the smallest
amount of code
I have every seen. The browser window believes there is only one type of
object in the whole
universe. This is the ultimate abstraction to a client application. The
tyeps of issues the
solutions solves included:-
1. Security ( In terms of general interface guidelines i.e. preventing the
users doing
something upfront - not error messaging)
2. Thin Client (Java Application, Applet and/or even JSP) through extreme
code reduction
3. Localization (This can be done from a console by non-programmers without
having to edit source code
- more powerful then resource files)
4. Management (IT Operations - security, deployment, extreme configuration,
localization....)
5. Performance (This client is fast trust me)
6. Consistency (Objects are rendered and can be interacted with everywhere
in a consistent manner)
These and much more are achievabe because of the dynamic nature of the whole
system.
Some of details behind this solution will be appearing in a future issue of
JavaReport
I believe the June or July.
[richard]
A very interesting post from Jonthan Weedon. It just makes me more curious
about IAS then I was before.
[william]
I am glad somebody has woken up from their coma or taken their blinkers off.
I recieved alot of
bad/rude emails a while back because of my belief (frequently posted) that
IAS is far superior
to anything out there. I had no ulterior motives other than the promoting of
better technology to
fellow professionals (I have the best intentions). I have used many other
application servers and have
seen people burnt by them. I decided to correct this and fight against the
poor quality of some
servers which for non-technical reasons seem to be leaders in this industry.
I will continue to
do so until either they close-up or produce something that is of acceptable
quality. The goldrush is over.
If your not going to do it right then why do it at all.
[richard]
As the number of quires grows you will need to create more and more detail
object types. These are not very reusable since they are fairly specific to
the
type of data needed, so you end up with hundreds of these little detail
objects
and the programmers have to learn to use each one.
[william]
Have your every used outlook? Do you think that every time I add a field to
the view that
outlook performs I query? I hope not. Let the user determine what she or he
needs to see of the model.
You do not have to create many details objects acting as different views on
the same data this to me
is the responsibility of the view component. I would be silly to constantly
go back to the server everytime
the user changes the viewing preferences if your client allows this. Have I
understood you correctly.
[richard]
In addition these little detail objects can not be used in automated
software that builds reports or
tables because their interfaces are so specific.
[william]
Sorry Richard but you are wrong. In fact the opposite is true. Its more
powerful than the resultset.
What I have done is nothing new (what is in this industry?). I have succeed
because of the fact the
I have fully utilized current tools and technologies, and created an
incredibly well designed
implementation.
kind regards
William Louth
Inspired Consultancy
> -----Original Message-----
> From: Richard Monson-Haefel [SMTP:[EMAIL PROTECTED]]
> Sent: Thursday, April 27, 2000 7:35 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Cached Rowsets-do we need to use them
>
> William,
>
> A very interesting post from Jonthan Weedon. It just makes me more curious
> about
> IAS then I was before.
>
> For the sake of argument lets assume that the IAS is incredibly well
> designed
> that there is very little overhead in obtaining and accessing Entity beans
> within the server (from bean to bean). I find this difficult to believe
> having
> worked on these issues myself, but I'm willing to concede that point so
> that we
> can focus on a more important issue which is reusability. So lets assume
> that
> performance is not the issue and focus for a second on usability.
>
> I would argue that the ResultSet 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).
>
> Now I'll give you the benefit of the doubt and assume that you have been
> talking
> about sending arrays of structures that only contain the fields requested.
> So
> lets assume that you have 3 different queries for different kinds of data.
> Shown below is the structures or "detail" objects you might use:
>
> public class EmployeeSalaryDetail implements Serializable {
> public int employeeID;
> public String name;
> public double salary;
> }
> public class PaidInvoices implements Serializalble {
> public int id
> public int customer;
> public double amount;
> public Date paydate;
> }
> public class RoomSchedule implements Serizliable {
> public int roomNumber;
> public Date from;
> public Date to;
> public int employeeID;
> }
>
> As the number of quires grows you will need to create more and more detail
> object types. These are not very reusable since they are fairly specific
> to the
> type of data needed, so you end up with hundreds of these little detail
> objects
> and the programmers have to learn to use each one. In addition these
> little
> detail objects can not be used in automated software that builds reports
> or
> tables because their interfaces are so specific.
>
> The other option is to have a limited number of detail object with lots of
> fields. When you do a query you only populate the fields you need and
> nothing
> more. The problem with this is that you create incomplete objects that
> only
> have a fraction of their data. Its up to the client developer to restrict
> themselves to just the data that is actually populated into the object.
> This,
> IMO, breaks all OO conventions which encourage each object to be
> functionally
> complete (unless its abstract) and would be poor OO.
>
> The ResultSet design suffers from none of these problems.
>
> Richard
>
> --
> Richard Monson-Haefel
> Author of Enterprise JavaBeans, 2nd Edition
> Published by O'Reilly & Associates
> http://www.EjbNow.com
>
>
>
***********************************************************************
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".
