On 1/15/07, Al Boldi <[EMAIL PROTECTED]> wrote:
>    4. *Tight coupling to a data access API.* The BDE allows us to swap
> aliases when you want to change databases, but what if you want to
> switch from BDE data access, to ADO, IBObjects, Direct Oracle Access
> (DOA), ClientDataSet or our own custom data format? (This is not the
> fault of the data aware controls, but is still a problem with the
> component-on-form style of developing.)

What problem?  Can you explain?

Switching from the BDE to lets say Direct Oracle Access.  You would
have to replace all you TDatabase, TQuery, TStoredProc components with
TDOADatabase, TDOAQuery and TDOAStoredProc components.  You can't do
that with a search and replace and you can't do that at runtime.  Also
if you listened to BDE specific exceptions, you would have to change
that code as well.  All this is not a trivial change!

Using patterns is great, but "how are they / should they be" dependant on the
OPF?

Design patterns are not dependant on the OPF, it is rather the OPF is
based on known design patterns to solve known problems.  This also
gives developers (knowing design patterns) a much quicker
understanding of the framework. The framework also benefits of the
well thought out solutions described in Design Patterns.

Can you give an example of a simple generic implementation?

To find out more about the Model-GUI-Mediators (MGM) pattern, have a look at:
 http://www.atug.com/andypatterns/mgm.htm

For my implementation which rather uses RTTI to set and get Object
property values have a look at:
 http://tinyurl.com/y5akb5

and the following units.
 tiGenericEditMediators.pas
 tiGenericListMediators.pas
 tiCompositeMediators.pas

My implementation is more complicate that it needs to be, just because
I wanted to implement a Generic Mediator class I can use for any Edit
components (TEdit, TTrackBar, etc).  If can be simplified a lot!  Also
my mediators use TtiObject as the base object for the Model, but that
is because I use tiOPF. If is very easy to change to any TObject
descendant class that as RTTI enabled and a simple implementation of
the Observer pattern.  MGM is a compound pattern based on the Observer
and Mediator pattern.


--
Graeme Geldenhuys

There's no place like S34° 03.168'  E018° 49.342'

_________________________________________________________________
    To unsubscribe: mail [EMAIL PROTECTED] with
               "unsubscribe" as the Subject
  archives at http://www.lazarus.freepascal.org/mailarchives

Reply via email to