 |
BorlandTalk.com
Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
siegfriedn
Guest
|
 Posted: Sun Oct 30, 2005 1:32 pm Post subject: TDataset and the OPF |
 |
|
Hi,
What are you using as your super anscestor of your BOs?
I have always wondered why can't one use a TDataset with persistent
field definitions as the anscestor for your BO? Normally in all the
examples the BO in a OPF is derived from TObject which leaves you to
implement a lot of the functionality already in the TDataset in your BO
class.
Also if you use a TClientDataset with persistent fields defs with the
data persisted to the database via a provider on the application server
- ala the Delphi way. Can this not also be considered an OPF? I know
there could be an issue with field data types, but this can be overcome
by dynamically resetting the datatypes according to those on the
database at runtime. This way some of the good that comes from OPF is
already there. (another example is the kbmMW works with memtables)
Basically is it not a waste of time to implement your OPF from
'scratch'? It may also take too long to implement in a business
environment.Sometimes I feel this way, but it is definitely more fun<g>
Sorry, for commiting a herecy by queationing the 'purity' of OOD for an
OPF in this newsgroup <g>
Siegs
|
|
| Back to top |
|
 |
Joanna Carter [TeamB]
Guest
|
| Posted: Sun Oct 30, 2005 1:48 pm Post subject: Re: TDataset and the OPF |
|
|
"siegfriedn" <sniedinger@yahoodotcodotuk> a écrit dans le message de news:
[email]4364bb91 (AT) newsgroups (DOT) borland.com[/email]...
| Quote: | What are you using as your super anscestor of your BOs?
|
TBaseObject
| Quote: | I have always wondered why can't one use a TDataset with persistent
field definitions as the anscestor for your BO? Normally in all the
examples the BO in a OPF is derived from TObject which leaves you to
implement a lot of the functionality already in the TDataset in your BO
class.
|
Unfortunately, the behaviour defined in TDataset is excessive for most OO
system requirements and includes a lot of database paradigm properties and
events. TDataset, as defined in Delphi for Win32 is all about connecting UI
controls directly to database tables and fields.
If you derive from TDataset, you can create your own dataset that allows you
to use lists of objects instead of tables but, once again, this type of
dataset really belongs as an intermediary between your BOs and the UI
controls, not as a substitute for those BOs.
| Quote: | Also if you use a TClientDataset with persistent fields defs with the
data persisted to the database via a provider on the application server
- ala the Delphi way. Can this not also be considered an OPF? I know
there could be an issue with field data types, but this can be overcome
by dynamically resetting the datatypes according to those on the
database at runtime. This way some of the good that comes from OPF is
already there. (another example is the kbmMW works with memtables)
|
The big difference between implementing your own base BO class and OPF, and
using database-type components is that BO classes will not necessarily map
1-1 to relational database table definitions; especially when it comes to
list properties that are composite inside another BO class and should not be
added to except by methods on the containing BO class.
| Quote: | Basically is it not a waste of time to implement your OPF from
'scratch'? It may also take too long to implement in a business
environment.Sometimes I feel this way, but it is definitely more fun
|
Once you have written your first OPF, subsequent use of it is a breeze and
you should never need to implement it again for future apps. As to the time
needed to re-implement it, if necessary, we have just ported our Delphi OPF
to C# 2.0 using generics in about three weeks.
| Quote: | Sorry, for commiting a herecy by queationing the 'purity' of OOD for an
OPF in this newsgroup
|
The classes you mention are still based on OOD, they are just not
necessarily the right classes for the job in hand. :-)
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
|
|
| Back to top |
|
|
Bob Dawson
Guest
|
| Posted: Sun Oct 30, 2005 2:08 pm Post subject: Re: TDataset and the OPF |
|
|
"siegfriedn" wrote
| Quote: | What are you using as your super ancestor of your BOs?
|
Well, TAbstractBObject (but ultimately TObject).
| Quote: | I have always wondered why can't one use a TDataset with persistent
field definitions as the ancestor for your BO? Normally in all the
examples the BO in a OPF is derived from TObject which leaves you to
implement a lot of the functionality already in the TDataset in your BO
class.
|
Not sure what you mean--my BO classes do not emulate dataset behavior at
all, and don't even contain an internal dataset as a composite member. What
methods do you see as common?
| Quote: | Basically is it not a waste of time to implement your OPF from
'scratch'?
|
Certainly, if better alternatives exist.
| Quote: | It may also take too long to implement in a business
environment.
|
Unless reuse or extended maintenance is anticipated, that could be said for
any design effort. There's a big difference between just 'making it work'
and 'getting it right' that always has to be justified. You have to decide
for any project which makes more sense. Of course, if you have built up a
considerable infrastructure already, the cost of doing it right goes way
down.
| Quote: | Sorry, for committing a heresy by questioning the 'purity' of OOD for an
OPF in this newsgroup
|
Not a problem.
bobD
|
|
| Back to top |
|
|
Wayne Niddery [TeamB]
Guest
|
| Posted: Sun Oct 30, 2005 4:07 pm Post subject: Re: TDataset and the OPF |
|
|
siegfriedn wrote:
| Quote: |
I have always wondered why can't one use a TDataset with persistent
field definitions as the anscestor for your BO? Normally in all the
examples the BO in a OPF is derived from TObject which leaves you to
implement a lot of the functionality already in the TDataset in your
BO class.
|
This restricts BOs to simply being object mirrors of database tables or
result sets. While it's frequently the case that a BO will be one-on-one
with rows in a table, it is also very desirable to have BOs that implement
business logic that spans any number of tables and do not directly map to
the database.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"The legitimate powers of government extend to such acts only as are
injurious to others. But it does me no injury for my neighbor to say
there are twenty gods, or no God. It neither picks my pocket nor breaks
my leg." - Thomas Jefferson
|
|
| Back to top |
|
|
C4D - Kim Madsen
Guest
|
| Posted: Sun Oct 30, 2005 5:02 pm Post subject: Re: TDataset and the OPF |
|
|
Hi,
FTR, there is nothing in TDataset terminology that require things to be related to one single db table, or even have
anything to do with databases at all.
A TDataset in a detached n-tier setup is nothing but a data container.
The difference is the ability to name properties and methods on a typical class and to provide 'user' side functionality
via custom methods etc.
But there is really no difference in using a TDataset as the base and adding those methods and properties.
The big advantage of doing so is actually the easier access to data, the builtin searching and sorting abilities etc
that for example kbmMemTable provides.
Granted, there is also a disadvantage... higher memory overhead compared to simple classes and more provided features
that can 'confuse' users.
kbmMW is a good example of a setup that dont restrict a TDataset to being a result of a single table. It can be the
result of a combo of tables via a join, from multiple databases, from other external sources, objects, emails etc. Its
all abstracted out and because of that abstraction level, it even allows for updating the sources with new data later
on, even under some transactional control.
--
best regards
Kim Madsen
[email]kbm (AT) components4developers (DOT) com[/email]
www.components4developers.com
The best components for the best developers
kbmMW - kbmMemTable - kbmWABD - kbmX10
"Wayne Niddery [TeamB]" <wniddery (AT) chaffaci (DOT) on.ca> skrev i en meddelelse news:4364efab (AT) newsgroups (DOT) borland.com...
| Quote: | siegfriedn wrote:
I have always wondered why can't one use a TDataset with persistent
field definitions as the anscestor for your BO? Normally in all the
examples the BO in a OPF is derived from TObject which leaves you to
implement a lot of the functionality already in the TDataset in your
BO class.
This restricts BOs to simply being object mirrors of database tables or result sets. While it's frequently the case
that a BO will be one-on-one with rows in a table, it is also very desirable to have BOs that implement business logic
that spans any number of tables and do not directly map to the database.
--
Wayne Niddery - Logic Fundamentals, Inc. (www.logicfundamentals.com)
RADBooks: http://www.logicfundamentals.com/RADBooks.html
"The legitimate powers of government extend to such acts only as are
injurious to others. But it does me no injury for my neighbor to say
there are twenty gods, or no God. It neither picks my pocket nor breaks
my leg." - Thomas Jefferson
|
|
|
| Back to top |
|
|
siegfriedn
Guest
|
| Posted: Mon Oct 31, 2005 12:57 am Post subject: Re: TDataset and the OPF |
|
|
C4D - Kim Madsen wrote:
| Quote: |
FTR, there is nothing in TDataset terminology that require things to be related to one single db table, or even have
anything to do with databases at all.
A TDataset in a detached n-tier setup is nothing but a data container.
|
Exactly why I was wondering why one can not also use a
TDataset/TkbmMemtable as the anscestor. As I said the only problem would
be mapping the field datatypes from the database with the persistent
fields defined in your class - same for an OPF. Also when you resolve
you need to 'handle' each BO class persistence to the database
specifically on the app server - same for an OPF.
My BO class derived from TInterfacedObject is starting to resemble a
'dataset' - hence why I was wondering... Granted it is more lightweight,
but when you need to add indexes and sorting algorithms it starts to
feel like one is re-inventing the wheel a bit!
I can also now understand why Delphi and knmMW functionality were done
in the way they are - very clevery modelled on an OPF for RAD!
However, I still prefer the 'lightweight BO' way, but it initially takes
a long time to get it right. For me the main advantage is the control
you have over your data and the ability to choose which Data to stream
back to the server for efficiency. (kbmMW works wonderfully well for me
in this setup too!)
Siegs
|
|
| Back to top |
|
|
Joanna Carter [TeamB]
Guest
|
| Posted: Mon Oct 31, 2005 10:14 am Post subject: Re: TDataset and the OPF |
|
|
"siegfriedn" <sniedinger@yahoodotcodotuk> a écrit dans le message de news:
4365e8a9$1 (AT) newsgroups (DOT) borland.com...
| Quote: | If you derive from TDataset, you can create your own dataset that allows
you
to use lists of objects instead of tables but,
That's how I see the TDataset being used in the OPF. One does not always
need to connect a 'TDataset' to data-aware controls nor 1:1 to the
database to make it useful.
|
In the scenario where you use a TDataset derivative to connect to data-aware
controls to properties of objects, the TDataset derivative is not a part of
the OPF but of the UI. It is effectively an Adapter class that allows you to
use data-aware controls with objects
| Quote: | What do you effectively mean? Would the BO just be like a provider that
populated a TDataset and persisted the data back to the server from the
client?
|
The BO is a class that holds, not only data, but also the logic related the
business class in question. In a properly layered application the BO classes
know nothing about databases or storage at all. A properly designed OPF
should allow you to design your BO classes in such a way that there is
absolutely no code in them that relates to storage.
| Quote: | Indeed, especially in a client-server scenario, but one could perhaps
have an intermediate 'datatype translator/convertor' on the app server
to get around it? One also needs to map the database field types to your
BO anyways.
|
That is the purpose of the OPF; to translate data stored in properties of
objects to data stored in fields of tables. In my OPF, I only have one query
component, one database component and one transaction component. The SQL
classes inside the OPF take an instance of a BO class and use the metadata
provided by the TBaseObject class to create appropriate SQL statements to
CRUD the objects.
| Quote: | True, but to get your first OPF can be timeconsuming and risky in a
short deadline development environment.
|
If you have a short deadline development environment, you do not have the
opportunity to write your oxn OPF from scratch; however, if you already have
one written, then using it will enable faster development than a non-OO
project as you will not have to develop the database, stored procs, etc.
| Quote: | Almost all the applications I work/have worked on are database driven
applications. Since one would really need most of the methods in a
TDataset type class for these applications, Is it not wise to rather
derive from a TDataset or equivalent to safe time? (especially QA)
|
Database driven projects are not as easy to convert to using an OPF.
Ideally, the database is generated from the BO class definitions, not the
other way round. In the case of having to use a legacy database still be
accessed by other programs, you would have to use the OPF in a slightly
different way as an Adapter that maps your BO class definitons into the
existing database tables. But if there are no other applications sharing the
data, then the best possible approach is to redesign the database where
necessary to match the class definitions.
| Quote: | I have read that ECO is also supposed to do OPF 'the wizard way' Have
you had a chance to work with it? I guess once you already have your OPF
it does not make sense to just use the latest and the greatest for the
sake of it..
|
Yes, but although ECO allows you to map to a legacy database, the best
design approach is still to use ECO to design your classes and then let it
generate the database for you.
| Quote: | Btw my BO anscestor is the TInterfacedObject.
|
That too was my ultimate ancestor; TBaseObject derives from
TInterfacedObject and adds functionality that allows me to query the private
ValueType objects held for each property in the BO classes derived from
TBaseObject.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
|
|
| Back to top |
|
|
Joanna Carter [TeamB]
Guest
|
| Posted: Mon Oct 31, 2005 10:20 am Post subject: Re: TDataset and the OPF |
|
|
"siegfriedn" <sniedinger@yahoodotcodotuk> a écrit dans le message de news:
43655c40$1 (AT) newsgroups (DOT) borland.com...
| Quote: | Exactly why I was wondering why one can not also use a
TDataset/TkbmMemtable as the anscestor.
|
Because a BO class is not really a table it is a combination of properties
and methods which, not only hold data but also describe the internal
business logic of the intended class.
| Quote: | My BO class derived from TInterfacedObject is starting to resemble a
'dataset' - hence why I was wondering... Granted it is more lightweight,
but when you need to add indexes and sorting algorithms it starts to
feel like one is re-inventing the wheel a bit!
|
If you have all this kind of logic inside your base BO class, then you are
definitely doing it wrong  All this behaviour really belongs in the OPF.
| Quote: | I can also now understand why Delphi and knmMW functionality were done
in the way they are - very clevery modelled on an OPF for RAD!
|
As good as kbmMW is at its job, that job is to act as middleware, not an OPF
which is a means of storage.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
|
|
| Back to top |
|
|
Joanna Carter [TeamB]
Guest
|
| Posted: Mon Oct 31, 2005 10:33 am Post subject: Re: TDataset and the OPF |
|
|
"siegfriedn" <sniedinger@yahoodotcodotuk> a écrit dans le message de news:
[email]4365ea0d (AT) newsgroups (DOT) borland.com[/email]...
| Quote: | | Perhaps I have worked with databse driven applications too long
|
A common problem to newbies here :-)
| Quote: | What I meant was that when a BO stores a number of 'records' that need
to then have sort and indexing capabilities. Or do I have the whole
thing wrong in the sense that a BO will always only contain one record?
|
A BO doesn't "store" or "contain" records at all, its job is to represent a
business concept for a single entity. You may also end up with list classes
that represent lists of BOs.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
|
|
| Back to top |
|
|
Joanna Carter [TeamB]
Guest
|
| Posted: Mon Oct 31, 2005 10:45 am Post subject: Re: TDataset and the OPF |
|
|
"siegfriedn" <sniedinger@yahoodotcodotuk> a écrit dans le message de news:
4365edb4$1 (AT) newsgroups (DOT) borland.com...
| Quote: | Aha, This is perhaps where I am misunderstanding BO's in a OPF!
Where do you maintain the cursor to your recordset in the OPF then?
Surely you are not fetching row by row from the middle tier/database?
|
If you are retrieving lists of objects then you can either retrieve the
entire list in one go, or you can use a list broker to feed the list on an
"as required" basis. Don't forget that the OPF should also be capable of
retrieveing single objects as well as lists.
| Quote: | Can you provide a high level framework layout example in a 3 tier
architecture environment (Databasae - App server - Rich-Client) that
shows the different objects that cooperate on the different tiers?
|
Here is my overview :
Database
OPF
Business Layer
Model View Presenter framework
GUI
Of course, all these layers can happily exist on one machine; after all, it
is the fact that the layers exist that makes application development easier
and more flexible.
In the case of a multi-machine client/server sceanrio, usually the OPF is
situated on the same machine as the Database, but there is no reason why it
cannot access the Database remotely.
In the client/server situation, the OPF can also be a "server" in that it
becomes an Object Broker that dispenses objects to clients on other machines
via a proxy/stub system that allows the clients to use a proxy of the main
OPF class to talk to the real OPF on another machine.
The MVP framework also allows you to separate the UI client to another
machine from the business layer; think about the possibilities of creating
web clients to the same BO classes that standard Windows forms client can
display.
Joanna
--
Joanna Carter [TeamB]
Consultant Software Engineer
|
|
| Back to top |
|
|
Richard H
Guest
|
| Posted: Mon Oct 31, 2005 10:51 am Post subject: Re: TDataset and the OPF |
|
|
| Quote: | . The SQL
classes inside the OPF take an instance of a BO class and use the metadata
provided by the TBaseObject class to create appropriate SQL statements to
CRUD the objects.
|
Hello Joanaa
er... what means CRUD?
thanks
Richard
|
|
| Back to top |
|
|
siegfriedn
Guest
|
| Posted: Mon Oct 31, 2005 10:57 am Post subject: Re: TDataset and the OPF |
|
|
Joanna Carter [TeamB] wrote:
...
| Quote: | If you derive from TDataset, you can create your own dataset that allows you
to use lists of objects instead of tables but,
|
That's how I see the TDataset being used in the OPF. One does not always
need to connect a 'TDataset' to data-aware controls nor 1:1 to the
database to make it useful.
| Quote: | ..once again, this type of
dataset really belongs as an intermediary between your BOs and the UI
controls, not as a substitute for those BOs.
|
What do you effectively mean? Would the BO just be like a provider that
populated a TDataset and persisted the data back to the server from the
client?
...
| Quote: | | Also if you use a TClientDataset with persistent fields defs with the
...
The big difference between implementing your own base BO class and OPF, and
using database-type components is that BO classes will not necessarily map
1-1 to relational database table definitions; especially when it comes to
list properties that are composite inside another BO class and should not be
added to except by methods on the containing BO class.
|
Indeed, especially in a client-server scenario, but one could perhaps
have an intermediate 'datatype translator/convertor' on the app server
to get around it? One also needs to map the database field types to your
BO anyways.
...
| Quote: | Once you have written your first OPF, subsequent use of it is a breeze and
you should never need to implement it again for future apps. As to the time
needed to re-implement it, if necessary, we have just ported our Delphi OPF
to C# 2.0 using generics in about three weeks.
|
True, but to get your first OPF can be timeconsuming and risky in a
short deadline development environment.
Almost all the applications I work/have worked on are database driven
applications. Since one would really need most of the methods in a
TDataset type class for these applications, Is it not wise to rather
derive from a TDataset or equivalent to safe time? (especially QA)
I have read that ECO is also supposed to do OPF 'the wizard way' Have
you had a chance to work with it? I guess once you already have your OPF
it does not make sense to just use the latest and the greatest for the
sake of it..
Btw my BO anscestor is the TInterfacedObject.
Siegs
|
|
| Back to top |
|
|
Abdullah Kauchali
Guest
|
| Posted: Mon Oct 31, 2005 10:58 am Post subject: Re: TDataset and the OPF |
|
|
Joanna Carter [TeamB] wrote:
| Quote: | the OPF but of the UI. It is effectively an Adapter class that allows you to
use data-aware controls with objects
|
That seems like a narrow interpretation of the use of TDataset (and
all its derivatives or cousins).
TDataset does or can be modified to do /much more/ than just allow
the use of data-aware controls. It can encapsulate business logic
around it, it can be serialised to disk or across the wire, it does
sorting, it does filtering, it can do tuple-based calculations, it
allows you to iterate (navigate) through it, it can enforce data
consistency rules as specified in the database ... yeah, and one of
its qualities is that it has a built-in MVC architecture (with its own
event-listener framework) to support data-aware controls.
Can it be used in a non-visual environment like the middle-tier?
Absolutely. Can its use be considered as an efficient solution in
the middle-tier compared to typical OPF models? Of course yes!
TDataSet, because it has no concept of tightly defined hierarchies
as found in OPF designs, allows you to use the very same principles of
efficient and consistent data modeling in your /process space/.
TDataset allows for in-memory dataset normalisation to be possible,
because it is based on "table" logic.
| Quote: | Database driven projects are not as easy to convert to using an OPF.
|
Indeed.
| Quote: | Yes, but although ECO allows you to map to a legacy database, the best
design approach is still to use ECO to design your classes and then let it
generate the database for you.
|
Database design first! Sorry. :)
|
|
| Back to top |
|
|
Abdullah Kauchali
Guest
|
| Posted: Mon Oct 31, 2005 10:59 am Post subject: Re: TDataset and the OPF |
|
|
Richard H wrote:
| Quote: | er... what means CRUD?
|
Create, Read, Update and Delete.
|
|
| Back to top |
|
|
siegfriedn
Guest
|
| Posted: Mon Oct 31, 2005 11:02 am Post subject: Re: TDataset and the OPF |
|
|
Bob Dawson wrote:
| Quote: |
Not sure what you mean--my BO classes do not emulate dataset behavior at
all, and don't even contain an internal dataset as a composite member. What
methods do you see as common?
|
Perhaps I have worked with databse driven applications too long <g>
What I meant was that when a BO stores a number of 'records' that need
to then have sort and indexing capabilities. Or do I have the whole
thing wrong in the sense that a BO will always only contain one record?
Thanks,
Siegs
|
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
