Al Boldi wrote:
You see, trying to create an OPF as a separate layer that
connects to the db via a broker is just broken by design, as this will
introduce a tremendous overhead due to the dual caching problem.
I agree with you that this will cause some overhead, but it is not as
much as you figured. The main bottleneck of an OPF is the database
access, how the OPF builds DMLs, do object cache, lazy loading, bulk
retrieving, etc.
In fact, the correct way forward seems to be to implement the OPF as the
broker, just like you implement the broker against a specific db-lib. What
you get is a db specific OPF that wraps the broker inside it in a native
fashion.
If I understood you correctly, this means build an OPF tied to an
specific database, and this isn't a nice approach. In the current design
I have:
user <-> mvp <-> data type <-> opf engine broker <->
connection broker (tied with) db engine
You can change every part without changing the others. A small overhead
do exist actually, 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.
--
Joao Morais
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
