Subject | RE: [IBO] TDataSet vs. Native |
---|---|
Author | Ondrej Kelle |
Post date | 2001-01-06T11:18:26Z |
Hello Helen,
the virtualized TDataSet from Delphi 4 and later? I liked the concept of
virtual TDataSet a lot. I realize I'm not qualified to argue with you, but
still I don't see how TDataSet forces anyone towards a fat client.
Honestly, I would love to hear some arguments to support your statements.
Could you explain this a bit more, please. Perhaps I yet have to go through
a mental transition such as you describe.
Let's suppose I use IBX for example. I can define views on the Interbase
server to make client select statements simpler, with triggers so they
appear to the client as updatable tables. Most of the development is thus
done on the server. Once that's done, I enjoy the fact that writing a client
application is very easy and fast - I'd drop a few TIBQuery components, data
sources, data-aware controls and I'm done. When I need some data which does
not need to be linked with the GUI, I'll use the TIBSQL component. All (or
almost all) functionality is coded on the server in views, triggers, and
stored procedures. Is this scenario what you call fat client?
differently. I have just recently started using IBO and until now I had no
such experience of enlightenment. What I see at the moment is:
- TIB_Query with so many TStrings properties that this makes me feel I'm not
using a compiler but writing some kind of script, like VBA.
BTW, what about properties like FieldsGridLabel, isn't that GUI related?
(but then the VCL TField is no different, either)
- all those .imp and .int files which Delphi doesn't recognize for syntax
highlighting or code insight. That's very annoying, and I would appreciate
if someone can provide a workaround.
- a strange naming convention throughout the code, using underscores (a lot
of them).
- a few very basic and almost useless tutorials (but I admit I have made no
intensive search yet for other sources of information)
- a lot of code to read and try to understand (but I admit I haven't even
started)
- many various UI components, but they only make sense with IBO.
Please I'm not trying to criticise. I'm showing you my feelings and probably
the typical feelings of the average programmer when they have their first
look at IBO and what probably scares them off. Please I don't mean to start
a flame.
I'm also probably mentally biased against one man projects because I've seen
a few truly horrible results of this. But that again is my own problem, and
I'll try and force myself to remain objective.
Thanks for any and all ideas.
TOndrej
> that the fatAre you talking about BDE TDataSet from Delphi 3 or does this also include
> client VCL can't meet without a LOT of manual code, i.e. more
> fat. Look at
> some of the monstrous data-handling monoliths we have all had
> to write
> during our time in TDataset country. It's where RAD turns on
> itself and
> makes hard work out of something that a different class
> ancestry would have
> avoided altogether.
> The Delphi VCL is heavily focused on the GUI - its database
> functionality
> is all about bringing data processing right up to the surface of the
> GUI.
the virtualized TDataSet from Delphi 4 and later? I liked the concept of
virtual TDataSet a lot. I realize I'm not qualified to argue with you, but
still I don't see how TDataSet forces anyone towards a fat client.
Honestly, I would love to hear some arguments to support your statements.
Could you explain this a bit more, please. Perhaps I yet have to go through
a mental transition such as you describe.
Let's suppose I use IBX for example. I can define views on the Interbase
server to make client select statements simpler, with triggers so they
appear to the client as updatable tables. Most of the development is thus
done on the server. Once that's done, I enjoy the fact that writing a client
application is very easy and fast - I'd drop a few TIBQuery components, data
sources, data-aware controls and I'm done. When I need some data which does
not need to be linked with the GUI, I'll use the TIBSQL component. All (or
almost all) functionality is coded on the server in views, triggers, and
stored procedures. Is this scenario what you call fat client?
> That's why TIB_* really makes you rethink your perception of C/sI like those rare moments when a new idea makes you start thinking
> programming and opens doors you didn't know were there in developing
> object-oriented interfaces for relational data structures.
differently. I have just recently started using IBO and until now I had no
such experience of enlightenment. What I see at the moment is:
- TIB_Query with so many TStrings properties that this makes me feel I'm not
using a compiler but writing some kind of script, like VBA.
BTW, what about properties like FieldsGridLabel, isn't that GUI related?
(but then the VCL TField is no different, either)
- all those .imp and .int files which Delphi doesn't recognize for syntax
highlighting or code insight. That's very annoying, and I would appreciate
if someone can provide a workaround.
- a strange naming convention throughout the code, using underscores (a lot
of them).
- a few very basic and almost useless tutorials (but I admit I have made no
intensive search yet for other sources of information)
- a lot of code to read and try to understand (but I admit I haven't even
started)
- many various UI components, but they only make sense with IBO.
Please I'm not trying to criticise. I'm showing you my feelings and probably
the typical feelings of the average programmer when they have their first
look at IBO and what probably scares them off. Please I don't mean to start
a flame.
I'm also probably mentally biased against one man projects because I've seen
a few truly horrible results of this. But that again is my own problem, and
I'll try and force myself to remain objective.
Thanks for any and all ideas.
TOndrej