 |
BorlandTalk.com Borland discussion newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Mark Reichert Guest
|
Posted: Tue Jan 16, 2007 5:00 am Post subject: Data Access Layer and Data Modules |
|
|
I want to make a Data Module deal only with direct database access and put a
Data Access Object between it and the applicable form or frame. From a
previous thread I conclude that this isn't an original idea. What I can't
quite grasp is some of the mechanics.
Do you encapsulate the Start of a Transaction and Open/ExecuteQuery in one
Datamodule method and the Close, Commit in another?
In between, do you populate Data Module fields immediately and have the Data
Object collect it afterwards? This would have the two advantages of keeping
the transaction time short and keep the field names just in the Data Module.
I also suppose that if you are getting data from one table for certain IDs
and from two other tables for other IDs, the Data Module should be the one
to deal with that detail as well, rather than the Data Access Object knowing
there are different tables involved.
Are there any books or good examples with have Data Access Objects
intereacting with Data Modules? |
|
| Back to top |
|
 |
Mark Reichert Guest
|
Posted: Tue Jan 16, 2007 9:34 pm Post subject: Re: Data Access Layer and Data Modules |
|
|
"Mark Reichert" <mark (AT) messagelink (DOT) com> wrote in message
news:45ac06a3$1 (AT) newsgroups (DOT) borland.com...
| Quote: | Do you encapsulate the Start of a Transaction and Open/ExecuteQuery in one
Datamodule method and the Close, Commit in another?
In between, do you populate Data Module fields immediately and have the
Data Object collect it afterwards? This would have the two advantages of
keeping the transaction time short and keep the field names just in the
Data Module. I also suppose that if you are getting data from one table
for certain IDs and from two other tables for other IDs, the Data Module
should be the one to deal with that detail as well, rather than the Data
Access Object knowing there are different tables involved.
|
While I'm waiting for other answers, I've decided to start experimenting
with something I found in a thread here in 2005. Someone (who I would give
attribution to if I sure he wanted to be mentioned) wrote that before he
started using a full fledged OPF, he use the intermediate step of something
like this: DataModule.SaveCustomer(ACustomer: TCustomer).
In other words, letting the Data Module as well as the Forms know about the
business class, but only so it can load up the class with info from the
databases or save data from the classes to the database. I know classes
well enough to be comfortable with passing the data around through this
method, though there's still the issue of when you load and when you save.
I still haven't managed to get a frame properly initialized on startup
because I can't find the exact spot given Delphi's quirky order of
activation.
http://groups.google.com/group/borland.public.delphi.ide/msg/2225f83d74cf6920?hl=en& |
|
| Back to top |
|
 |
Mark Reichert Guest
|
Posted: Thu Jan 18, 2007 3:03 am Post subject: Re: Data Access Layer and Data Modules |
|
|
"Mark Reichert" <mark (AT) messagelink (DOT) com> wrote in message
news:45acefcc$1 (AT) newsgroups (DOT) borland.com...
| Quote: | "Mark Reichert" <mark (AT) messagelink (DOT) com> wrote in message
news:45ac06a3$1 (AT) newsgroups (DOT) borland.com...
While I'm waiting for other answers, I've decided to start experimenting
with something I found in a thread here in 2005. Someone (who I would
give attribution to if I sure he wanted to be mentioned) wrote that before
he started using a full fledged OPF, he use the intermediate step of
something like this: DataModule.SaveCustomer(ACustomer: TCustomer).
In other words, letting the Data Module as well as the Forms know about
the business class, but only so it can load up the class with info from
the databases or save data from the classes to the database. I know
classes well enough to be comfortable with passing the data around through
this method, though there's still the issue of when you load and when you
save.
|
Or there is TCustomer.SaveToDatabase(ADataModule: TDataModule).
I have no idea if that would work any better, but it would keep the Data
Module from knowing anything about the business class, even for the purpose
of loading or saving. |
|
| Back to top |
|
 |
Lars Frische Guest
|
Posted: Thu Jan 18, 2007 9:12 am Post subject: Re: Data Access Layer and Data Modules |
|
|
Mark Reichert wrote:
| Quote: | Or there is TCustomer.SaveToDatabase(ADataModule: TDataModule).
|
The problem with this approach is that you cannot easily exchange the
persistence layer (flat file/xml vs. database X vs. database Y). If you
are 100% percent sure that this won't likely change then this is
probably a viable (if not really nice) way.
Cheers
Lars
--
Lars Frische
Software Developer
Test Maschinen Technik GmbH
Germany
===
http://www.eddyMax.com
http://www.kontrolltechnik.com |
|
| Back to top |
|
 |
Mark Reichert Guest
|
Posted: Thu Jan 18, 2007 9:17 pm Post subject: Re: Data Access Layer and Data Modules |
|
|
"Lars Frische" <nospam (AT) eddymax (DOT) com> wrote in message
news:45af22ad$1 (AT) newsgroups (DOT) borland.com...
| Quote: | Mark Reichert wrote:
Or there is TCustomer.SaveToDatabase(ADataModule: TDataModule).
The problem with this approach is that you cannot easily exchange the
persistence layer (flat file/xml vs. database X vs. database Y). If you
are 100% percent sure that this won't likely change then this is probably
a viable (if not really nice) way.
|
Only if you run into something you can't do inside a TDataModule. I was
assuming that if you passed a TDataModule variable as a parameter, the
Business Class could see the TDataModule properties you've add, properties
that correspond to Business Class members. The Business Class wouldn't have
to know much if anything about where or how the TDataModule loads from or
saves to storage.
Please tell me if I'm incorrect and where or what I should be reading to
learn about real world practical solutions. |
|
| Back to top |
|
 |
Franz-Leo Chomse Guest
|
Posted: Thu Jan 18, 2007 11:14 pm Post subject: Re: Data Access Layer and Data Modules |
|
|
| Quote: | Only if you run into something you can't do inside a TDataModule. I was
assuming that if you passed a TDataModule variable as a parameter, the
Business Class could see the TDataModule properties you've add, properties
that correspond to Business Class members. The Business Class wouldn't have
to know much if anything about where or how the TDataModule loads from or
saves to storage.
|
Only if the business class uses a sort of dynamic binding like access
properties via RTTI.
If you use static binding you only see the original TDataModule
properties.
Regards from Germany
Franz-Leo |
|
| Back to top |
|
 |
Mark Reichert Guest
|
Posted: Thu Jan 18, 2007 11:46 pm Post subject: Re: Data Access Layer and Data Modules |
|
|
"Franz-Leo Chomse" <franz-leo.chomse (AT) samac (DOT) de> wrote in message
news:odavq2dr7icajd008ih6mlfdet7s2j9n25 (AT) 4ax (DOT) com...
| Quote: |
Only if you run into something you can't do inside a TDataModule. I was
assuming that if you passed a TDataModule variable as a parameter, the
Business Class could see the TDataModule properties you've add, properties
that correspond to Business Class members. The Business Class wouldn't
have
to know much if anything about where or how the TDataModule loads from or
saves to storage.
Only if the business class uses a sort of dynamic binding like access
properties via RTTI.
If you use static binding you only see the original TDataModule
properties.
|
I'll have to pass the paramater as the actual TDataModule descendant class
type then.
Perhaps I should make a generic TDataModule descendant class with the proper
property declarations only, make that the class I pass, and descend any
specific instance with the actual dataset work from that. I'll do a search
for example of anybody doing that.
I know I'm behind the times on this (if ahead here at this company), but I
haven't found any solid examples of using business classes that still allow
me to use Data Modules, hence my meandering posts here. |
|
| 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
|
|