Encapsulation vs. performance

Question

We are creating a J2EE application with an O-R mapper to solve the persistence problems. We plan to create Java objects which encapsulate certain aspects by creating a service interface. These services use persistent objects backed by some database tables.
Now we have some decisions which need information of all kinds of services. With SQL you would do a big join over a lot of tables and get a small result. Using OO you would ask service A getting 5000 objects and merge it with the result of service B getting 6000 objects...
I don't have to mention that the OO version is unbearably slow. The SQL version is quite fast but breaks encapsulation. The writer of the query has to know the implementation details of all services.
Is there any solution? Somthing like the service provides a part of a query and the caller "joins" them with its own query?

Answer 1

>
Is there any solution? Somthing like the service
provides a part of a query and the caller "joins"
them with its own query?This is easy to generalize given that a service does know the attibutes.
Each attribute generates the following java properties...
           class Attribute
               String op1;
               String op2;
               Operand operand;
This is wrapped in a service type
          class SingleServiceQuery
                String serviceName
                Collection of Attributes
          class  ServiceQuery
                Collection of SingleServiceQuery
In the database layer you have a generalized routine to map the serviceName to the database, and attribute types and names.
You can derive this dynamically or simply insist that the service descriptor itself provide (even do it the database if you want.)
Commonality is based on common attribute names.
The query is built dynamically.