1-10 start/2007-02-28/1

I don't think the Search<DomainObject> concept that João described above was completly understood. The suggestion was to consider a view in a database as a regular table. So, if your persistence framework maps objects to tables, it can map and object into a view. If you then ask the framework to provide all objects of that type (a readAll) it will provide objects representing the result of a complex query "transparently".

Well, to me the main problem with this approach is the materialization of the objects resulting from a search, plus all the related objects needed to present the results, when such materialization was (probably) already made by the database engine.

I'll present the same problem as I did to you personally yesterday: Consider a costumer with orders. You wish to list all costumers plus it's most recent order. You would create an index on the date of the order, and join the costumer table with the order table on the most recent order. The query will discard quickly the orders we don't want because it simply transverses the BTree to find our order.

However, when done in memory, upon materializing the results, you'll have to find the most recent order by iterating manually through the orders of the costumer, materializing them all to do the comparison and find the most recent. This is a very simple example that (I hope) can demonstrate my point.