Al Boldi wrote:
do object cache, lazy loading, bulk retrieving, etc.
That's where things become interesting, because you have to figure out how to
interface with your non-OO db, aka relational-DB, without incurring any
duplicate overhead.
Interesting and amusing.
an OPF should not be considered an
independent layer, but rather as a wrapper/converter/adapter to the non-OO
db,
An OPF and its connection brokers consist of an independent layer that
binds objects of an oo model and a storage mechanism.
A small overhead do exist actually,
I don't think it's small, unless you mean small apps which deal with textual
data only. For large apps that deal with blobs, the overhead may bring down
your system.
No, small overhead even to applications that handle large objects. There
are three points to consider: 1. the real bottleneck is in the database
and in the network; 2. moving data between layers doesn't mean big
overhead due to refcount of ansistrings or other managed objects; 3.
lazy loading of objects and attributes mixed with bulk retrieving.
and the way to remove it is writing a connection
broker that doesn't depend of a db suite like SQLdb or Zeos, and that
doesn't depend of the tdataset as well.
If you do it this way, then you are actually implementing proxies, and
proxies should not be used unless there is a need for them like for
border-gateways, because proxies add overhead.
I think you meant wrappers. And yes, wrappers to SQLdbs are necessary in
this case, because implement wrappers to database API at this stage of
the project demands an effort that I would like to use to other more
important tasks like tests, docs and the expert.
What you may want to try is to refactor the OPF, dataBroker, and
dbConnectionLib into their respective layering components, and then
recompose a native OPF wrapper based on those layering components. This
should give a decoupled system while maintaining native performance.
Perhaps what you are proposing is something I have already implemented.
I don't use any db* class and have created an abstract data access to
improve speed as much as possible (or as I can) -- writing wrappers to
database APIs in future versions. Have a look in the code.
--
Joao Morais
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
