Graeme Geldenhuys wrote: > On 1/13/07, Al Boldi <[EMAIL PROTECTED]> wrote: > > If you are verse in OOP, there is really no need for an OPF, as an OPF > > only aids you in plumbing up your classes, while limiting you to the > > extent of the specific BusinessObject. > > I think you are missing the point of a OPF framework completely! The > OPF framework is there to persist (save) you objects to permanent > storage. Be that a text file (XML, CSV, TAB, etc) or a relational > database (Firebird, Oracle, DB2, etc). And if the OPF framework is > design correctly (as in the case of tiOPF) you can change the back-end > database even at runtime and nothing else needs to change in your > business objects or application. One of the demos in tiOPF is where > you load data from a CSV file, change the backend persistence layer > while the app is running and then save the data again, but this time > into a Firebird DB. All with 3 lines of code. > > You should be able to say APerson.Save and not care how it gets saved, > but knowing that it has been done.
You can do that with TTable/TQuery too, and with TClientDataSet you can even do it in a disconnected way, and then reconnect to the backend of your choice with less than 3 lines of code. 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. > The tiOPF base classes also do not limit you in any way regarding your > Business Object design. For example the tiOPF framework doesn't use > Interfaces at all. I wanted that, so created my own > TInterfacedTIObject descending from the tiOPF's base TtiObject class. > This helped me implement Event Listeners like Java does. I implemented > the Observer pattern based on Interfaces instead of Objects. Sure, you can always extend, but what did you gain from using the OPF? > Also an OPF normally has some really useful helper functions you can > use. In the case of tiOPF, have a look in Core/tiUtils.pas or > GUI/tiGUIUtils.pas Ok, you gained these helpers, but if they are specific to the OPF, they cause you to be locked into TiOPF. A standardized OPF interface could probably address these shortcomings. > I'm not done converting the documentation to fpdoc format, but the > full documentation is in the .pas units. Have a look at: > http://opensoft.homeip.net/tiopf/core/tiutils/index-5.html > > > I would rather see some work put into a powerful Class-Editor, inlined > > into > > InstantObjects is know for there GUI class editors, but the > InstantObjects framework has other limitations I cannot live with, > where tiOPF doesn't have that problem. I have thought of creating GUI > class editors for Lazarus and the tiOPF framework but decided it > wasn't needed. I have an extensive set of "code templates" in Lazarus > which allows me to build my business objects in seconds. > > For example. > I type: poa <and press Ctrl-J> > > and get a complete class layout. I have the same for the > implementation section of my classes and for my SQL visitors. By the > way, poa stands for "Persistent Object Abstract" :-) Yes, good example. We need more code helpers. > > the IDE, while being able to import/export UML. > > I spoke to someone at the end of last year in this mailing list or in > the fpc-pascal mailing list (can't remember), where they started UML > support in Lazaras. Exporting UML from code, etc.. Great! Thanks! -- Al _________________________________________________________________ To unsubscribe: mail [EMAIL PROTECTED] with "unsubscribe" as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
