tiOPF vs Bold

This is an extract from a conversation on the Australian Delphi User Group's mailing list:

Q: What are the technical advantages of using tiOPF over Bold...so exclude things like cost, ease of use and what-not...

In my view the biggest advantage of tiOPF over Bold is the ability to customise your data-access to suit different data base schemas. Bold did introduce a sort of way to do this, but it was less than optimal. Bold requires you to use the Bold generated database structure.

Whether this is an issue depends on whether you can specify the db structure your self or not. There are some advantages to being 'locked' out of the schema.
 
Can tiOPF integrate with ModelMaker?

Not in a higher abstraction way like Bold does. In tiOPF using MM is like using MM with any other Pascal code, the model directly reflects the level of abstraction of the code. In Bold the level of abstraction is higher and the code generator adds all the gory details for you.

In my opinion the one of the real hot aspects of Bold over any of the other OPF's I have seen generally available for Delphi is OCL. Having OCL is fantastic and hugely reduces the glue code often found in GUI's or even the domain objects themselves.
 
See I really like Bold (just from having a quick play around,  and from all that I've read that can be done with it), but being a small software house I don't know if my superiors will be willing to buy the software for only one project... (remember we are a web-development company)....so tiOPF is favourable to the decision makers in that regard...

Unfortunately the bean counters tend to have trouble with return on investment sometimes. In the scheme of things the cost of D7A is negligible to the whole project cost. If it can improve the reliability, speed of development and maintainability to the value of 100's of man hours what is the actual saving?
 
I just need convincing that tiOPF can do a lot of what Bold  can do, and I'm sold....

Basically they are very different beasts. Bold is a lot more than what tiOPF attempts to be, yet tiOPF in its simplicity is more flexible in some areas. Like everything the answer is not black and white. You really need to play with both to see which you prefer.

A *massive* advantage of tiOPF is you have the full source. With Bold you *do not* get the core source files, although you do get some of the source. A counter argument with Bold is you get support available from Borland and 3rd party component venders. ( check out www.boldbox.com for some links and products).
 
Cheers,

Anthony Richardson

Comparing BOLD with tiOPF is kind of like comparing WordPad with MSOffice. There are time when WordPad will be the right choice, and there are times when everything that MSOffice gives you is required (along with the feature bloat and the huge footprint).

There are some very cool features that you get with BOLD that will always be beyond the tiOPF, or are buried deep towards the bottom of our to-do list. Some thing that spring to mind (from Anthony’s talk on BOLD at the ADUG symposium):

Real-time synchronisation of GUI with object model.
Generate the database from the model
Generate the Delphi code from the model

What the tiOPF does give you is total ownership and control over the framework code. If it can’t do what you want it to do – then change it. (eg, we don’t currently have MySQL support as you have requested, but you could write a MySQL persistence layer in about 4 hours). With the tiOPF, it is also possible to interact with a legacy database (or one you have no control over the design of.)

The tiOPF is also based on some well established principles like the Visitor, Composite and Adaptor patterns – with a bit of Ambler thrown in.

A compelling argument for BOLD/ECO over tiOPF might be that the former will add more value to your CV than the latter.

HTH.

Peter.