Subject | Re: [IBO] Managing Transactions |
---|---|
Author | Nando Dessena |
Post date | 2001-08-30T16:37:44Z |
Jason et al,
access components and client side business logic; this means that a form
instantiates a private copy of a datamodule it needs (and passes its
"context" to it) giving me the chance to separate the data access logic
(and code) from the GUI.
The needed interactions between datamodule and form are coded with
specific interfaces (methods for form->dm notifications and events for
the other way round).
So, you can take advantage of module separation and at the same time
have each form using a different transaction context.
The Screen VCL object does a good job to help using datamodules this
way, but I have yet to explore if the benefits are available to
TDataSource users only or TIB_DataSource also.
Ciao
--
____
_/\/ando
> I think it is nice to use more than one transaction to allow the users toFWIW, I do use datamodules, primarily as private containers for data
> have more than one instance of a form at a time. This means you don't use
> datamodules so much. Only for global things. Otherwise, you cannot have
> isolated form instances with their own unique transaction contexts.
access components and client side business logic; this means that a form
instantiates a private copy of a datamodule it needs (and passes its
"context" to it) giving me the chance to separate the data access logic
(and code) from the GUI.
The needed interactions between datamodule and form are coded with
specific interfaces (methods for form->dm notifications and events for
the other way round).
So, you can take advantage of module separation and at the same time
have each form using a different transaction context.
The Screen VCL object does a good job to help using datamodules this
way, but I have yet to explore if the benefits are available to
TDataSource users only or TIB_DataSource also.
Ciao
--
____
_/\/ando