And I still didn't really answer your question.

There really isn't anything that allows you to retrieve objects directly
froma database, which is why I mentioned the OPF idea. A database is not
modelled on tha same paradigm as an object model; the database uses a
relational model which is subtly different from an object model.

e.g.

database :

OrderLine
- ID: integer
- OrderID: integer
- Quantity: integer
- ProductID: integer
- UnitPrice: float
- Total: float

Order
- ID: integer
- Ref: string
- Date: DateTime
- CustomerID: integer
- Total: float

object model :

OrderLine
- ID: integer
- Quantity: integer
- Product: Product
- UnitPrice: float
- Total: float

Order
- ID: integer
- Ref: string
- Date: DateTime
- Customer: Customer
- Lines: List<OrderLine>
- Total: float

Notice that in the relational model, the Order table has no knowledge of the
OrderLine table but the OrderLine table has to have a foreign key field to
link its records to a particular record in the Order Table; there may be
additional referential integrity constraints and things like cascade
deletion to ensure that when an Order is deleted, all its Lines are also
deleted.

Using an OO approach, we can dispense with the foreign key from the Line to
the Order as the Order already knows about its Lines; in fact, there really
is no need for the Line to know about the Order, as in the relational model.
Notice also that we do not use integer IDs to link object together, but
instead real references to real objects.

It is this  "impedance mismatch" between the relational model and the object
model that is resolved in an OPF. A mapping hierarchy lets us specify the
relational foreign key field links without polluting the object model. In
fact all a relational database behind an OPF has to do is simple single
table selects, updates and deletes, most of the time, as all the integrity
between objects is taken care of in the business object layer.

Joanna

You really must separate the areas of displaying, managing and storing
objects :-)

Ideally, large quantities of objects should be *stored* in a database.

How the objects are *managed* depends on quantities and other intangibles.
If you want to manage large quantities, then you would consider building a
broker which will page the objects into an in-memory list as required

*Displaying* the objects requires that your UI components will "ask" the
list for items, either on a one by one basis or a page at a time.

If you build your list class correctly, then it can surface events which can
be handled by a broker. The idea being that when the list is asked for, say,
item 45, the GetItem method would check to see if that item had already been
retrieved and, if not, would fire the ItemRequired event passing the index
required; the broker would note the index and check how many objects would
have to be retrieved to cover that index number. IT is always best to page
objects to save time, so 45 on a 10 page strategy would mean loading at
least four pages of objects.

You could also remove unused objects when they are no longer required, but
this will depend on the speed requirements of the program as to whether this
is reasonable or not.

Sorting objects that have been stored in a database and which are being
drawn into a list is usually best done by issuing SQL against the database
with a sort clause. Sorting the list means calling a Sort method on the list
class which is used to fire an event which is captured by the broker, which
will reload the list with objects sorted in the required order.

As to populating "large" objects; you are best working with partially loaded
objects for the purposes of browsing in a list, only loading all the
properties when a full object is selected for editing.

Looking at your message, it would seem like you are moving in this direction
anyway :-)

Joanna