Graeme Geldenhuys wrote:
> On 1/13/07, Al Boldi <[EMAIL PROTECTED]> wrote:
> > OPF is really meant as a glue between OOP and the DBMS, to yield an
> > ODBMS interface on the client side, for seamless OOP to DBMS
> > integration. This may save you some coding, but only for the price of
> > an additional setup of object properties, as OFP introduces yet another
> > layer.
>
> There is no question that the tools that come with Delphi/Lazarus can
> be used to build a database application very, very quickly. The power
> of the combination of the TDatabase, TQuery, TDataSource and TDBEdit
> is incredible. The problem is that with every TDatabase or TQuery you
> drop on a TDataModule, you have tied yourself more closely to the
> specific database vendor (using vendor specific components). With
> every TDBEdit added to a form, you have coupled yourself to that
> particular field name in the database.
Agreed 100%. I never liked the split TEdit/TDBEdit approach, and it looks
obviously wrong.
> 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?
> 1. The most powerful feature of the tiOPF has to be the Visitor
> pattern. For us the
> business, and the model of that business, is everything and the
> Visitor pattern allows us to painlessly traverse the 'model' and
> perform a specific action across a hierarchy of related entities. As a
> result, it assists in allowing us to focus more on the business and
> less on the technical code.
Using patterns is great, but "how are they / should they be" dependant on the
OPF?
> 6. Model-GUI-Mediators for enabling any standard GUI component to
> become Object Aware. There is a lot more standard non-DB Components
> than DB Components.
If this is true, then that's really your generic OPF.
Can you give an example of a simple generic implementation?
> > Ok, you gained these helpers, but if they are specific to the OPF, they
> > cause you to be locked into TiOPF.
>
> If you look at the code of tiUtils.pas you will see over 90% of the
> functions are not specific to the tiOPF framework. I use a lot of
> those functions in small utility apps without using the tiOPF
> framework.
So your argument, using an OPF to get helpers, becomes only 10% valid.
Still, I think OPF tries to address a valid issue, yet the non-standard
approach is what makes it just another stop-gap solution.
Again, a standardized OPF interface definition could probably address these
issues. Do you think this could be feasible?
Thanks!
--
Al
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
