arthur alexander wrote:
> As a number of individuals have responded, they create their own
> "custom" classes to deal with serializing the data out of the ResultSet
> into a 'locally' managed "non-database-related" class.
>
> This is the whole design intent of the CachedRowSet, but it will not
> be a custom implementation that differs from one project/vendor/user
> to the next, but is reusable across both internal projects and vendor
> collaborative works, such as commercial beans.
>
> You could argue that, just by it's packaging in the javax.sql package,
> or whatever package it ends up in, that it is "database related." This
> is no different from a custom class that knows how to serialize a java.sql.
> ResultSet object. Any such object must be database "aware."
>
If a business object would be created for every single row you retrieve, and there
are no relationships between these objects, I could buy into the idea of using
CachedRowSet as an internal storage mechanism. However, that simple scenario has
not been common in my experience with "real life" applications. My business
objects often have direct references to each other, and I sometimes need to
collapse detail rows from the database into a Vector or other collection returned
by a higher level object.
Or course, in my designs I resuse these same beans in the applications that create
and update the underlying database contents (with JDBC-aware, but not
database-specific, logic in a store() method), so I'm not having to create
anything new just for use in JSP pages, either.
Craig McClanahan
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
