Board index » delphi » Datamodule vs. datasources in forms

Datamodule vs. datasources in forms

OK, In the past I have put all data sources, tables, queries, etc in one
or more data modules.  However, in some cases (where a datasource and
table are only accessed by one form) I would like to place the datasource
and table on the form which uses them.  Since I generally prefer to
instantiate forms as they are used, and to only have tables active that
are actually in use, having them on the form makes this easier (and easier
for another programmer to read).  Otherwise, I have to add code to
activate and deactivate the tables in the code which calls the form (much
more elegant to do this in the OnCreate or OnDestroy of the form).

The only issues I can think of is that each form must then USE the DBxxxx
units, instead of just the datamodule unit.  Also, I would still need to
define a central location for the TSession - either in a datamodule or the
main form.

Is there any reason why I shouldn't keep the Data Access controls on the
form that they are used?  Am I costing my application any performance,
functionality, or stability?

Any reply to my question is greatly appreciated.

Keith Rome
high...@linknet.net

 

Re:Datamodule vs. datasources in forms


Quote
"Keith Rome" <high...@linknet.net> wrote:
>Is there any reason why I shouldn't keep the Data Access controls on the
>form that they are used?  Am I costing my application any performance,
>functionality, or stability?

Good question.

My opinion is that it is almost always best to put the data access
controls in a data module or on a form that is used like a data
module.

Here's a few reasons off the top of my head...

1) If you ever need to have more than 1 form based on that data model,
you can do it without making changes.

2) If you decide later to split the form into 2 or more forms that
work together, you don't disturb the data model.

3) If you decide later to combine several forms into one, you don't
disturb the data model.

4) It provides a place to centrally locate business rules and keeps
them out of the User Interface.  This is especially important for
client-server because if you need to go to a 3-tier architecture
later, you can do it more easily.

Regards,

David Orme
:======================================================:
: David J. Orme             Coconut Palm Software, Inc.
:  "Delphi Intranet Solutions for your business needs"
:            http://www.computervision.com
:======================================================:

Re:Datamodule vs. datasources in forms


Quote
Keith Rome wrote:

> OK, In the past I have put all data sources, tables, queries, etc in one
> or more data modules.  However, in some cases (where a datasource and
> table are only accessed by one form) I would like to place the datasource
> and table on the form which uses them.  Since I generally prefer to
> instantiate forms as they are used, and to only have tables active that
> are actually in use, having them on the form makes this easier (and easier
> for another programmer to read).  Otherwise, I have to add code to
> activate and deactivate the tables in the code which calls the form (much
> more elegant to do this in the OnCreate or OnDestroy of the form).

> The only issues I can think of is that each form must then USE the DBxxxx
> units, instead of just the datamodule unit.  Also, I would still need to
> define a central location for the TSession - either in a datamodule or the
> main form.

> Is there any reason why I shouldn't keep the Data Access controls on the
> form that they are used?  Am I costing my application any performance,
> functionality, or stability?

> Any reply to my question is greatly appreciated.

> Keith Rome
> high...@linknet.net

no performance , functionality, or stability costs as far as i can tell,
Ive developed many apps and converted them both ways to check these
issues myself. In fact, I find it easier to put the access controls on
the using form in some cases and in the datamodule in others. if I use
the data access in more than say... 2 forms then I use the data module,
otherwise... what's the point?

Re:Datamodule vs. datasources in forms


chris houghten <choug...@mcgh.org> wrote in article

Quote
> no performance , functionality, or stability costs as far as i can tell,
> Ive developed many apps and converted them both ways to check these
> issues myself. In fact, I find it easier to put the access controls on
> the using form in some cases and in the datamodule in others. if I use
> the data access in more than say... 2 forms then I use the data module,
> otherwise... what's the point?

The point for me is that I can seperate the interface and database handling
(business rules if you will allow me to use the term).  Once the business
rules are completed I can then switch interfaces without effecting the
business rules code in the datamodule.  I can create a new UI, slap the
datamodule into it, handle the posts, updates, etc in the interface and
allow the datamodule to handle exceptions, special posting rules, etc.

The only problem I have encountered is reporting back to interface when a
posting error has occured.  In proir products once an error or warning
occurs it is nice to set the focus back to the field which caused the
problem.  However, the datamodule has
no knowledge about the form, or the fields on that form.  I have work
around, which basically loops through the components on the form, looks for
a TDBEdit (or whatever) with a fieldname property of the offending field
name.

Mike J.

Re:Datamodule vs. datasources in forms


Quote
"Mike Johnson" <Mich...@SOTA.Com> wrote:
>The only problem I have encountered is reporting back to interface when a
>posting error has occured.  In proir products once an error or warning
>occurs it is nice to set the focus back to the field which caused the
>problem.  However, the datamodule has
>no knowledge about the form, or the fields on that form.  I have work
>around, which basically loops through the components on the form, looks for
>a TDBEdit (or whatever) with a fieldname property of the offending field
>name.

can  you kindly briefly explain how you loops through the componentns
on the form from the data module unit ?

thanks

Koh Yang Uei

Re:Datamodule vs. datasources in forms


Quote
Koh Yang Uei wrote:
> >no knowledge about the form, or the fields on that form.  I have work
> >around, which basically loops through the components on the form, looks for
> >a TDBEdit (or whatever) with a fieldname property of the offending field
> >name.

> can  you kindly briefly explain how you loops through the componentns
> on the form from the data module unit ?

And why are you doing it anyway? Check out the FocusControl method of the
TField component:

 "Declaration
  function FocusControl;

  Description
  Sets a form's focus to the first data-aware component associated with a
  TField. Use this method when doing record-oriented validation (for example,
  in the BeforePost event) since a field may be validated whether its
  associated data-aware components have focus."

Re:Datamodule vs. datasources in forms


One other way of doing this is to use the same event code on a single
unit. For all tables that use that table, after opening the table set the
event properties to the form or unit that contains the code e.g
Table1.BeforePost : = UnitX.Routine. The UnitX,Routine does not have to be
attached to a table, it only has to be of the same procedural type as the
BeforePost event.
This allows you to centralize certain events, similar to SQL triggers
using one set of codes, and other events handled differently according to
form.
For instance events triggered by a user editing the table manually can be
handled differently from computerised large scale data updates, where
certain checks are irrelevant, time wasting and some exceptions logged to
a file, rather than being aborted to wait for some response from the user.
When an error occurs, trap the owner of the TTable currently using the
code, that will be the form with the error.

Using Delphi 1, I find it easier to use this method, because having the
datasources on all forms in sync with the form current using the code is
can be undesirable in some cases.

Re:Datamodule vs. datasources in forms


John Petersen <jo...@post1.tele.dk> wrote in article
<31F017F1.1...@post1.tele.dk>...

Quote
> Koh Yang Uei wrote:

> > >no knowledge about the form, or the fields on that form.  I have work
> > >around, which basically loops through the components on the form,
looks for
> > >a TDBEdit (or whatever) with a fieldname property of the offending
field
> > >name.

> > can  you kindly briefly explain how you loops through the componentns
> > on the form from the data module unit ?

> And why are you doing it anyway? Check out the FocusControl method of the
> TField component:

>  "Declaration
>   function FocusControl;

>   Description
>   Sets a form's focus to the first data-aware component associated with a
>   TField. Use this method when doing record-oriented validation (for
example,
>   in the BeforePost event) since a field may be validated whether its
>   associated data-aware components have focus."

John :
Sure that will work if you are doing inline validation.  Frankly, most
accounting products (which is what I am working on) do validation when
attempting to post a record.  This is because some data is not valid based
upon criteria entered by the user.  For instance, when posting a credit
memo, I can allow them to select the GL Account they are going to post the
adjustment to before selecting the invoice number it is going to.  However,
when they click the "Post" event I need to see if they have a valid invoice
number, then if it is not valid (the adjustment date is before the invoice
date, no invoice number exists, many other problems) I need to set focus to
the field which is causing the error.

Koh :
Here is some sample code to scroll through the components on a form:

while ( I < ComponentCount ) AND ( bFound <> TRUE ) do begin
        if ( Components[I] is TDBEdit ) AND (
TDBEdit(Components[I]).DataField =                                 sFldName
) then begin
            bFound := TRUE;
            TDBEdit(Components[I]).SetFocus;
            end; // if ... then begin
        Inc(I);
        end; // while ... do begin

Mike

Re:Datamodule vs. datasources in forms


Koh Yang Uei <ab...@singnet.com.sg> wrote in article

Quote
> can  you kindly briefly explain how you loops through the componentns
> on the form from the data module unit ?

Sorry I don't do that in the data module.  I do it in the unit controlling
the form.  The datamodule returns the Field name that is causing the error.

The code to loop through controls on the form is :

    while ( I < ComponentCount ) AND ( bFound <> TRUE ) do begin
        if ( Components[I] is TDBEdit ) AND (
TDBEdit(Components[I]).DataField =                                        
                      sFldName ) then begin
            bFound := TRUE;
            TDBEdit(Components[I]).SetFocus;
            end; // if ... then begin
        Inc(I);
        end; // while ... do begin

Other Threads