Adam


Whilst out walking the dog I came up with a concept that might work - I haven't tried it yet but I'm going to tomorrow because its something I can use.

Forget datamodules - use frames. You can drop one on to each form that needs access thus achieving isolation and convenience.

I think that it should be possible to use them at design time as well as run time and once you've hooked things together - that's it.

Minor point - you'll have to change ShowModal to Show. I must say that I would be wary of allowing multiple editable invoices open simultaneously. The potential for cockups is quite high.

Roy Lambert

Adam H. wrote:

> I'm coming to a situation where I would like to start using
> datamodules as a variable declared on the form itself. This will
> allow me to have multiple instances of that form, where each form has
> it's own datamodule so I don't have to worry about conflicts /
> sharing resources.


My take on this, having done the same as you in the past, is to either
go fully RAD and have the data components on the form as well as the
visual components, or disconnect the datamodule and form completely and
define an "interface" for the business logic. Interface is in quotes
because I usually don't define an actual interface, but that's sort of
a technicality - it might be a plain class, or a class with derived
implementations.

Either way, the run-time multiple instances is a lot easier when you
don't have to wire up component links between the two.

--

Matthew Jones

Adam,

That's exactly how I do things here, mainly for large projects, so I agree with Raul - I also think it's the best approach.
I usually have one damodule with the Engine, Database and Session components as well as the logic for updating/checking/repairing the database and all the common database routines that are shared across the whole application, and then each form creates and destroys it's own instance of a second datamodule with the tables/queries/procedures, as needed.

--
Fernando Dias
[Team Elevate]

Hi Roy,

Thanks for your ideas. I've wanted to keep the datamodules separate
because in all honesty I'd be hard pressed to see or work with the
components once the datasets/datasources were on the form.

This may be different when I update to a newer version of Delphi and can
'hide' these - but a bit messy at the moment.

I think Frames may have the same problem.

It's OK though - I might just reconsider the need for creating
datamodules dynamically at the moment and stay with what works. As you
mention, it sounds like there's a lot more involved for the benefit.

Cheers

Adam.


> Adam
>
>
> Whilst out walking the dog I came up with a concept that might work - I haven't tried it yet but I'm going to tomorrow because its something I can use.
>
> Forget datamodules - use frames. You can drop one on to each form that needs access thus achieving isolation and convenience.
>
> I think that it should be possible to use them at design time as well as run time and once you've hooked things together - that's it.
>
> Minor point - you'll have to change ShowModal to Show. I must say that I would be wary of allowing multiple editable invoices open simultaneously. The potential for cockups is quite high.
>
> Roy Lambert
>

Hi Raul,

Thanks for your reply...

> I don't think there is a best way - we mostly use forms with datasources to handle design time linking.
>
> And then in our case datamodules are part of business logic (either form or thread) - sometimes the same form could have multiple datamodules as well.
>
> We reuse the forms heavily in various areas of our app (standalone and embedded)  and in some cases even across different apps (part of same product suite) so in our case the datamodule then provides data dynamically to datasource on form.

Can you please explain how your datamodule(s) provides data dynamically
to your form if you're linking them at design time?

Or have I misunderstood, and you are saying that you work two different
ways. (Datasources on forms at design time, or if the project requires
dynamic datamodules you design differently)?

Thanks & Regards

Adam.

Hi Matthew,

Thanks for your reply...

I'm not familiar with your second recommendation. (Design an interface
for the business logic). Is this using something like BOLD?  (Which I've
heard about briefly, but never used), or would you mind explaining a
simple example of how you would use an interface for a data component
that contains a lookup source?

Thanks & Regards

Adam.

On 3/01/2016 2:47 AM, Matthew Jones wrote:
> Adam H. wrote:
>
>> I'm coming to a situation where I would like to start using
>> datamodules as a variable declared on the form itself. This will
>> allow me to have multiple instances of that form, where each form has
>> it's own datamodule so I don't have to worry about conflicts /
>> sharing resources.
>
>
> My take on this, having done the same as you in the past, is to either
> go fully RAD and have the data components on the form as well as the
> visual components, or disconnect the datamodule and form completely and
> define an "interface" for the business logic. Interface is in quotes
> because I usually don't define an actual interface, but that's sort of
> a technicality - it might be a plain class, or a class with derived
> implementations.
>
> Either way, the run-time multiple instances is a lot easier when you
> don't have to wire up component links between the two.
>

Adam H. wrote:

> I'm not familiar with your second recommendation. (Design an
> interface for the business logic). Is this using something like BOLD?
> (Which I've heard about briefly, but never used), or would you mind
> explaining a simple example of how you would use an interface for a
> data component that contains a lookup source?

I'm talking about nothing more than a normal class, with defined
functions and procedures. "AddUser" "ApplyDiscount" "MarkInvoicePaid".
Functions that take the parameters required, and do just that task. The
function works out what database operations are needed, and applies
them. The UI is not linked to the database directly, so the underlying
implementation can be changed.

--

Matthew Jones

Adam

>I think Frames may have the same problem.

Frames seem to work OK here, as long as you don't drop engine, session or database on them since those are singletons (well the name for session & database)

What I did was just drop the table / query onto a frame, set Visible to false so it doesn't show at runtime. Drop on form where I wanted to use it and set top/left outside of the visible area and Bob's your uncle.

I can edit the tables on the frame, add persistent fields, calculated fields etc.

Its almost like using a datamodule, with the exception that you can drop it onto a form and there are a few events missing (eg OnCreate) so you have to have those as public procedures and call directly or build your own message handling in.

I need to do some more testing but I'm seriously thinking of converting my main app to this approach. It will take a chunk of messing around but will have a beneficial impact on maintenance. I may just have a look at writing my own container class (a cross between a frame & datamodule). I'm sure I've seen one somewhere way back.

Roy

<<
"Adam H." wrote:

Can you please explain how your datamodule(s) provides data dynamically
to your form if you're linking them at design time?
>>

At design time we just have a TDatasource and can link that to any of the DB aware controls and lay them out etc. In our case it's strictly a design exercise - we do not see any data in those controls.

We have  set of our own base forms with some common base functions to connect dataset to datasources etc. So in runtime the appropriate datamodule passes a dataset into the form using of those function and it gets connected.

It's not fully abstract as both dataset and form have to "know" what dataset it is but the coupling is very loose - only at the level of "this is customer dataset". This model works well for us since same forms are used in lots of places and they have no idea how the data is loaded so it gives us lot of freedom.

Delphi visual inheritance allows is to have some fairly complex forms in terms of class hierarchy as well as have combo forms that embed other forms on panels and such - and each one of those forms also runs fine as its own window.


<<
Or have I misunderstood, and you are saying that you work two different
ways. (Datasources on forms at design time, or if the project requires
dynamic datamodules you design differently)?
>>

We have datasources on forms at designtime but actual dataset for that datasource is attached at runtime - from whatever datamodule in that case provides the data. So the forms and datamodules are completely separate and not coupled in any way.

Raul