| Subject | Re: BDE, IBX and IBO |
|---|---|
| Author | Jason Wharton |
| Post date | 2000-11-15T20:23:59Z |
Aside from the fact that migrating an app from the BDE to IBO is magnitudes
easier than migrating to IBX, I think another thing that could be said is
that IBX and IBO differ in their underlying architecture and how they
interact with the API.
IBX has a "simpler" architecture that leaves much of the work up to the
developer to add any level of sophistication to an application as well as
some not so smooth behavior quirks that are impossible to work around. IBX
also does not abstract the API but instead it merely wraps it where
transactions are concerned. It does not touch your SQL in anyway and simply
brings records to the client if it has to do filtering, locates, record
counts, etc. It is ideal for small simple applications that don't require
much in the way of dynamic SQL, almost any amount of built-in
sophistication, etc. For example, apps that just need a thin wrapper to talk
to a DB and they have worked out all the other details (including all
possible SQL statements needed) of their application in other controls and
data containers, like the TClientDataset or custom buffers, etc.
IBO has a "richer" architecture that alleviates most all of the work
required to harness some sophisticated capabilities and it has smoothened
out all the quirky behaviors formerly in the BDE rather than introducing new
ones. Transaction handling in IBO fully abstracts the complexity of dealing
with them at the physical level like the BDE but it doesn't hide any of it
and exposes it so that as much control as is desired can be obtained. It is
ideal for people who want to work with the InterBase server in a
sophisticated manner with datasets that don't have quirks and smoothe, user
friendly transaction control. Also those who are comfortable having the IBO
engine arrange all the SQL necessary to keep the application
"server-centric" when do things like filters, locates, record counts,
searches, incremental searching, ranges, and so on. It is ideal for those
making applications that are tied closely to the server and want to interact
with it as efficiently as possible without doing a ton of work in their
application code base.
In short, the "do-it-yourselfers" who like to code nearly every aspect of
their applications in their own application code base will feel comfortable
with IBX. But, with IBO they would be irritated by the evidence of lots of
functionality that they don't know if is going to get in their way or not,
simply because they are not interested in it.
Where as others who like to have nice features to grow into and reap
time-saving benefits (as most of their code-sharing is already a part of the
tools they use) will be grateful for the wealth of functionality built into
IBO. They just like to learn solid, reliable and proven database interaction
techniques and stay focused on solving their business solutions in a
creative manner rather than so much humdrum of coding everything by hand and
working around quirks. They also enjoy day to day "discoveries" of just one
more aspect that has already been thought of and implemented in advance to
their benefit.
FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
"Craig Stuntz" <cstuntz@no_spam.vertexsoftware.com> wrote in message
news:3A12D926.8600A437@no_spam.vertexsoftware.com...
easier than migrating to IBX, I think another thing that could be said is
that IBX and IBO differ in their underlying architecture and how they
interact with the API.
IBX has a "simpler" architecture that leaves much of the work up to the
developer to add any level of sophistication to an application as well as
some not so smooth behavior quirks that are impossible to work around. IBX
also does not abstract the API but instead it merely wraps it where
transactions are concerned. It does not touch your SQL in anyway and simply
brings records to the client if it has to do filtering, locates, record
counts, etc. It is ideal for small simple applications that don't require
much in the way of dynamic SQL, almost any amount of built-in
sophistication, etc. For example, apps that just need a thin wrapper to talk
to a DB and they have worked out all the other details (including all
possible SQL statements needed) of their application in other controls and
data containers, like the TClientDataset or custom buffers, etc.
IBO has a "richer" architecture that alleviates most all of the work
required to harness some sophisticated capabilities and it has smoothened
out all the quirky behaviors formerly in the BDE rather than introducing new
ones. Transaction handling in IBO fully abstracts the complexity of dealing
with them at the physical level like the BDE but it doesn't hide any of it
and exposes it so that as much control as is desired can be obtained. It is
ideal for people who want to work with the InterBase server in a
sophisticated manner with datasets that don't have quirks and smoothe, user
friendly transaction control. Also those who are comfortable having the IBO
engine arrange all the SQL necessary to keep the application
"server-centric" when do things like filters, locates, record counts,
searches, incremental searching, ranges, and so on. It is ideal for those
making applications that are tied closely to the server and want to interact
with it as efficiently as possible without doing a ton of work in their
application code base.
In short, the "do-it-yourselfers" who like to code nearly every aspect of
their applications in their own application code base will feel comfortable
with IBX. But, with IBO they would be irritated by the evidence of lots of
functionality that they don't know if is going to get in their way or not,
simply because they are not interested in it.
Where as others who like to have nice features to grow into and reap
time-saving benefits (as most of their code-sharing is already a part of the
tools they use) will be grateful for the wealth of functionality built into
IBO. They just like to learn solid, reliable and proven database interaction
techniques and stay focused on solving their business solutions in a
creative manner rather than so much humdrum of coding everything by hand and
working around quirks. They also enjoy day to day "discoveries" of just one
more aspect that has already been thought of and implemented in advance to
their benefit.
FWIW,
Jason Wharton
CPS - Mesa AZ
http://www.ibobjects.com
"Craig Stuntz" <cstuntz@no_spam.vertexsoftware.com> wrote in message
news:3A12D926.8600A437@no_spam.vertexsoftware.com...
>
> Arturas Sirvydis wrote:
> >
> > I know this was discussed a lot, but still...
> > I'm exeprienced with IB4.0 and BDE.
> > And what would be the best choice now ?
> > IB6.01 of course... and? IBExpress ? IBO ? And why ?
>
> If you're used to the BDE, IBO's BDE-compatible components work much
> more like the BDE than the IBX components do. However, the "native" IBO
> components are substantially more different than the BDE than the IBX
> components are, so you can take your pick, there. The scale runs as
> follows
>
> <Like BDE> - BDE - IBO "BDE" - IBX - IBO "native" - <Unlike BDE>
>
> IMHO, both IBX and IBO are good component sets, but they are very
> different. Since you can download a trial version of IBO for free, and
> since IBX is always free, why not try them for yourself and see which
> approach you prefer? It shouldn't take very long to get a feel for the
> approach each component set uses.
>
> > Application speed is a crucial factor. So is the development time.
>
> Both are very fast performance wise -- substantially faster than the
> BDE. As for development time, well, that's up to you. Neither
> component set is particularly onerous to use, IMHO.
>
> HTH,
>
> -Craig
>
> --
> Craig Stuntz Vertex Systems Corporation
> Senior Developer http://www.vertexsoftware.com
>
> Delphi/InterBase weblog: http://delphi.weblogs.com