|
Understanding a ViewObject's Default RowSet and RowSetIterator
This picture tries to clear up another common confusion. In the UML diagram of BC4J client interfaces, you can see that a ViewObject defines the query that produces RowSets when that query is executed. It also defines the metadata describing the "shape" of a row in the result set of that query (e.g. names and datatypes of each column). A View Object can be used to produce multiple RowSet's.
Also, for any given RowSet you might want to be iterating through the rows using one or more independent "current record pointers". Indeed, any RowSet can have multiple iterators to handle this as shown in the UML diagram below.
In practice though, in most scenarios you will use a ViewObject to define a SQL query and you'll only really need to work with one "main" RowSet of results from that query at a time. You might parameterize the query using bind variables, and then set some new values for those bind variables and re-execute, but fundamentally you're just working with one main RowSet of that queries results, not many. To cater to this common usecase, the ViewObject extends the RowSet interface and it implements the RowSet methods (like executeQuery, and setWhereClauseParam for example) by delegating to a "default" RowSet instance that the view object manages for itself. Analogously, while multiple iterators on a RowSet is a nice feature when you need it, most of the time you don't need it. So, the RowSet interface extends the RowSetIterator interface and it implements the RowSetIterator methods (like next, previous, insertRow, etc.) by delegating to a "default" RowSetIterator instance that the RowSet manages for itself.
This let's you conveniently work with a view object, set it's where clause parameters, execute it's query, and iterate through the rows in the default rowset all using the single, handy ViewObject interface for the most common cases.
|
