Joao Morais wrote:
> 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,
Yes, that's the easy part.
> 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.
> > 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.
I know it does not sound nice, but an OPF should not be considered an
independent layer, but rather as a wrapper/converter/adapter to the non-OO
db, much like the connection broker, only the connection broker output is a
tdataset wheras the OPF should give you direct access to your native
objects.
> 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.
If you implement the OPF as a pluggable system, then you may do the same.
> 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.
> 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.
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.
Thanks!
--
Al
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
