Board index » delphi » Opinions sought on data modules

Opinions sought on data modules

Quote
"RussellA" <tryw...@msn.com.au> wrote:
>Bit of a newbie question

>Wondering whether its common practice and/or good or bad design to use data
>modules for tables which primarily supply form access.

>My limited experience sort of tells me that its better to for each form to
>be self contained with its own tables - but I would appreciate other input.

Russell,

I like data modules for three reasons:
1. It keeps the nonvisual clutter off my form. This is significant if
a form has 10 or 20 non-visual components on it. (Just because it's
called a data module doesn't mean it's limited to data-aware
components. A dm will hold any non-visual component.)
2. It puts all my database code in one place. There can be a lot of it
and it can get confusing mixing it up with form event code.
3. I can put functional routines together: all invoice handling here,
all inventory handling there. It saves repetition. Whenever a form
needs a service, I just call up that data module and use its routines.
One form can use more than one data module.  Also, I have a master
data module that handles the session, database connections and global
routines, like that for passwords.

There is one caveat. I started thinking that I could have one data
module for the whole application. That wound up having so much code in
it that it got out of hand and was totally unmanageable. Better to
focus the data module on one idea: one form, say, or one function.

Good luck.

Phil Cain
--

 

Re:Opinions sought on data modules


Bit of a newbie question

Wondering whether its common practice and/or good or bad design to use data
modules for tables which primarily supply form access.

My limited experience sort of tells me that its better to for each form to
be self contained with its own tables - but I would appreciate other input.

Thanks in advance
Russell

Re:Opinions sought on data modules


I you are sure the table will be used outside this form, you dont need
datamodule.But my experience is that you always develope the software a
grid, a report, and so on, and then a dataModule becomes very usefull.
Sraya
Quote
RussellA <tryw...@msn.com.au> wrote in message

news:831qq5$nfe8@forums.borland.com...
Quote
> Bit of a newbie question

> Wondering whether its common practice and/or good or bad design to use
data
> modules for tables which primarily supply form access.

> My limited experience sort of tells me that its better to for each form to
> be self contained with its own tables - but I would appreciate other
input.

> Thanks in advance
> Russell

Re:Opinions sought on data modules


Fr?n: Philip Cain <philc...@orelle.com>

Quote
> I like data modules for three reasons:
> 1. It keeps the nonvisual clutter off my form. This is significant if
> a form has 10 or 20 non-visual components on it. (Just because it's
> called a data module doesn't mean it's limited to data-aware
> components. A dm will hold any non-visual component.)

Philip,

Design question: When I want to change something on a form ( eg graying out
controls ) based on some condition/change in the tables, I end up putting
datasources on the form anyway. Usually they duplicate datasources allready
in the module.  Do you have  a smarter/cleaner solution for this?

Krister

Re:Opinions sought on data modules


Krister,

In my opinion, putting the datasource on the form IS the cleanest way of
doing this.  Putting the datasource controls on the form makes the form
independent of the actual datamodule used.  At the very least, it gives you
a nice clean break between the data and your user interface.  It also puts
data-driven user interface code in the form unit, where it belongs.

Quote
Krister Olsson wrote in message >
>Philip,

>Design question: When I want to change something on a form ( eg graying out
>controls ) based on some condition/change in the tables, I end up putting
>datasources on the form anyway. Usually they duplicate datasources allready
>in the module.  Do you have  a smarter/cleaner solution for this?

>Krister

Re:Opinions sought on data modules


Use Application.OnIdle instead.

Quote
"Krister Olsson" <gymcont...@alftarehab.se> wrote in message

news:832bqc$rrq5@forums.borland.com...
Quote
> Fr?n: Philip Cain <philc...@orelle.com>

> > I like data modules for three reasons:
> > 1. It keeps the nonvisual clutter off my form. This is significant if
> > a form has 10 or 20 non-visual components on it. (Just because it's
> > called a data module doesn't mean it's limited to data-aware
> > components. A dm will hold any non-visual component.)

> Philip,

> Design question: When I want to change something on a form ( eg graying
out
> controls ) based on some condition/change in the tables, I end up putting
> datasources on the form anyway. Usually they duplicate datasources
allready
> in the module.  Do you have  a smarter/cleaner solution for this?

> Krister

Re:Opinions sought on data modules


Quote
>Design question: When I want to change something on a form ( eg graying out
>controls ) based on some condition/change in the tables, I end up putting
>datasources on the form anyway. Usually they duplicate datasources allready
>in the module.  Do you have  a smarter/cleaner solution for this?

Krister,

You don't have to duplicate any components. Put the dataset and
datasource on the dm and refer to it directly from the form.

If a component refers to a datasource then do this:

        Button1.Enabled :=
myGrid.Datasource.Dataset.FieldByName('flag').AsInteger = 0;

or go directly to the dm for the information, this way:

        Button1.Enabled := MyDM.MyTable.FieldByName('flag').AsInteger = 0;

If you don't like all those long names then put a method on the dm:

function TMyDM.FlagOK: boolean;
begin
        Result := MyTable.FieldByName('flag').AsInteger = 0;
end;

Then, on your form, you can say:
        Button1.Enabled := MyDM.FlagOK;

Phil Cain
--

Re:Opinions sought on data modules


Philip,

Yes, I am using code similiar to that as well. Sorry for not being very
clear. My question was basically where (which event) to put the code. I put
datasources on the form to use the OnDataChange event like in this article
at UNDU:
"Using TDataSource to Improve Your User-Interface"
http://www.undu.com/Articles/980415a.htm
I was wondering if you did it differently, something like Art Begun's
suggestion to use Application.OnIdle perhaps?

Thanks,
Krister

Re:Opinions sought on data modules


Art,

Thanks. I will look at that.

Krister

Re:Opinions sought on data modules


Quote
Art Begun wrote:
> Use Application.OnIdle instead.

    Art's suggestion is fine, but I should also mention some other options
which may or may not work for you depending upon how you build your
application.

    If you use action lists, the actions (and the action list itself) will have
OnUpdate events, which function much like Application.OnIdle, except that they
are tied directly to the actions.

    You can also update your user interface in a DataSet's AfterScroll (for
multiple-record selections) or AfterOpen (for singleton result sets) events.

    -Craig

--
Craig Stuntz   cstuntz@no_spam.vertexsoftware.com
----------------  -----------------------------
Delphi Developer  Vertex Systems Corporation
& Cat Wrangler   http://www.vertexsoftware.com

Re:Opinions sought on data modules


I use datamodules for everything. If I need different procedures for
OnDataChange or any other event, I create them in the form unit and when
creating the form, I assign it's own event handler to whichever tables or
data sources need them. That way each form is self-contained and uses the
same global data sources. The obvious drawback to this, of course, is that
you can't represent that same table on two open forms simultaneously, But,
for me, this is a positive limitation because of the complexities of most of
the forms.

--

Woody
Black holes are where God divided by zero.

Quote
Krister Olsson <gymcont...@alftarehab.se> wrote in message

news:83558n$k9e7@forums.borland.com...
Quote
> Philip,

> Yes, I am using code similiar to that as well. Sorry for not being very
> clear. My question was basically where (which event) to put the code. I
put
> datasources on the form to use the OnDataChange event like in this article
> at UNDU:
> "Using TDataSource to Improve Your User-Interface"
> http://www.undu.com/Articles/980415a.htm
> I was wondering if you did it differently, something like Art Begun's
> suggestion to use Application.OnIdle perhaps?

> Thanks,
> Krister

Re:Opinions sought on data modules


Quote
"Krister Olsson" <gymcont...@alftarehab.se> wrote:
>Philip,

>Yes, I am using code similiar to that as well. Sorry for not being very
>clear. My question was basically where (which event) to put the code. I put
>datasources on the form to use the OnDataChange event like in this article
>at UNDU:
>"Using TDataSource to Improve Your User-Interface"
>http://www.undu.com/Articles/980415a.htm
>I was wondering if you did it differently, something like Art Begun's
>suggestion to use Application.OnIdle perhaps?

Krister,

Ah, I see what you mean. The problem is how to get the database  and
the form components to talk with one another when the database
components are, essentially, on a different form (in this case a data
module) I have to admit that I never thought of separating the
datasource from the dataset and putting the datasource on the form,
but I see how that might work.

There's nothing wrong with Matt Hamilton's approach. Still, I prefer
to keep the clutter entirely on the dm. I have worked out what can be
classified as three techniques for this:

The first is the one I've already explained. That is, writing
functions on the dm that the form can use. This is the approach I use
most of all.

The second is a bit less portable. I sometimes create a property on
the dm of the type TForm and I set that property with the calling
form. That way, the dm can refer to its own TForm property to get
access to the form and controls. There are some problems with this,
however. If two forms use the same instance of the dm, what becomes of
the property. Secondly, when coding something like a datasource event,
it's necessary to check RTTI for the name of the form (or the instance
type) to get the proper references to controls. And of course there is
the problem that the type is not really TForm; it's TMyForm. Sometimes
you have to be that specific and that can kill any hope of
reusability.

How much of a problem this is depends on your design. This isn't a
good idea, for example, if many forms use the same instance of the dm.
But If you clone the same form many times and each clone uses its own
instance of the dm, then there's no problem.

The third way is to send messages from the dm to the form, usually
with PostMessage. The only problem to solve here is to get the handle
of the calling form. There are several ways to do that. A simple way
would be to put the form itself in as an argument on calls to dm
methods, but you can't do that with datasource methods. I have a
global object in my current project that tracks the active form (about
like Screen.ActiveForm but for my application). That way I can get the
currently active form from anywhere in the app.

Regardless of the technique, however, I always use the same approach
in the form. Basically, I do not allow any of these many events to
change the form's controls directly, as Matt did. Rather, each of
these events change a flag in the form. The flag is typically a
boolean or an enumerated set. That way, these events can go about
their business of changing these flags whenever they want to. Flags
are just variable values, after all, and these events don't have to
know anything about the current state of the form and so don't have to
coordinate with visual component changes. All that is done in the
form.

Then, in the form, I almost invariably have a method called
SetControls. SetControls is the one and only place in the form where I
do things like enabling/disabling and turning visibility on and off.
In this method, I check the flags and set the appearance of the form.
No more looking about trying to find that obscure line where that edit
box keeps becoming disabled. In SetControls, I can also call dm
functions to find out stuff I need to do this. The overall effect is
that I divide the problem into two : one is catching the pertinent
events and the other is changing the form.

Finally, in the form only, whenever the user or the program does
something that might change the appearance of the form, I throw in a
call to SetControls. The fact that it uses mostly flags and quick
functions makes it run very fast and I never have to worry about
overusing it and the form becomes very responsive to the user.

This is all a bit too elaborate for simple programs, but when you get
into the bramble of an order processing system, say, divide and
conquer is the only way.

Phil Cain
--

Re:Opinions sought on data modules


I was just going to point out that
everytime a different form becomes
active, you can set application.onidle := ThisformsIdleroutine;
and have a differnent routine for each form
to set states of buttons etc on that form.
In between you need to set it to nil;

Quote
"Krister Olsson" <gymcont...@alftarehab.se> wrote in message

news:83558n$k9e7@forums.borland.com...
Quote
> Philip,

> Yes, I am using code similiar to that as well. Sorry for not being very
> clear. My question was basically where (which event) to put the code. I
put
> datasources on the form to use the OnDataChange event like in this article
> at UNDU:
> "Using TDataSource to Improve Your User-Interface"
> http://www.undu.com/Articles/980415a.htm
> I was wondering if you did it differently, something like Art Begun's
> suggestion to use Application.OnIdle perhaps?

> Thanks,
> Krister

Re:Opinions sought on data modules


Quote
Philip Cain wrote:
> There's nothing wrong with Matt Hamilton's approach. Still, I prefer
> to keep the clutter entirely on the dm.

    Matter of preference, I guess.  I don't consider DataSources (as distinct
from DataSets) to be clutter, as they encapsulate the connection from the
DataSets to the form's controls and therefore are relevent to the functionality
of the controls -- especially if you are using an OnDataChange handler to change
the user interface (as distinct from calling business logic).

    There is another argument for putting DataSources on Forms: If the Form
loads before the DataModule, RTTI won't be able to make property assignments
from components on the Form to components or methods on the DataModule.  The
components will become "disconnected."  The easiest way to guarantee that this
will not be a problem is to hard-code the assignments.  By putting the
DataSource on the Form, you have to make only a single assignment -- the
DataSource.DataSet.

Quote
> The first is the one I've already explained. That is, writing
> functions on the dm that the form can use. This is the approach I use
> most of all.

    I agree that this is best for business logic considerations.  For user
interface issues, I like to put the functions on the user interface itself, plus
it eliminates the second problem you refer to:

Quote
> If two forms use the same instance of the dm, what becomes of
> the property.
> <snip>
> Basically, I do not allow any of these many events to
> change the form's controls directly, as Matt did.

    I think this is a valid argument when you are referring to events which
happen on controls on anything other than the form (such as the datamodule).  If
you have a DataSource on the Form itself, I don't have a problem with letting it
change the Form which it belongs to.

    MHO,

    -Craig

--
Craig Stuntz   cstuntz@no_spam.vertexsoftware.com
----------------  -----------------------------
Delphi Developer  Vertex Systems Corporation
& Cat Wrangler   http://www.vertexsoftware.com

Re:Opinions sought on data modules


Quote
Craig Stuntz <cstuntz@no_spam.vertexsoftware.com> wrote:
>    Matter of preference, I guess.  

As you say.

Quote
>I don't consider DataSources (as distinct
>from DataSets) to be clutter, as they encapsulate the connection from the

Visual clutter, I mean. When a form as two or three datasets, it's no
problem, but I have some forms using as many as 20 datasets open
simultaneously. It's just easier to manage on a separate dm.

Thanks for your thoughts.

Phil Cain

--

Go to page: [1] [2]

Other Threads