[Lazarus] Delphi, Kylix or Lazarus multi-form DB app example

[Michael Van Canneyt]

On Thu, 5 Oct 2017, Graeme Geldenhuys via Lazarus wrote:

> On 2017-10-05 11:10, leledumbo via Lazarus wrote:
>> Because that defeats the purpose of a demo project:
>
> A "real world" example (or close to it) would also be a very valuable 
> source of information. Education for the masses. In the tiOPF project we 
> stuck to small-and-to-the-point demos for many years, and was constantly 
> bombarded with requests to make more real-world like examples, so they 
> can see how it all fits together.
>
>> After all, single or multi form doesn't differ much, it's just the way you
>> structure your project.
>
> And that is exactly my issue... What are the best practices? I haven't 
> done "prototype" (aka RAD) style development with Delphi or Lazarus in 
> over 10 years. I've long moved to a more OOP approach where I work with 
> actual business/entity objects. eg: AddressList.Load(), 
> lPerson.Address.Country = xyz etc, and not directly working with raw 
> table data in my applications.
>
> Last night I played with the prototype/RAD style development and found 
> in so frustrating - having things hard coded everywhere (eg: fields for 
> a DBGrid) etc and then when I change the data source my whole program 
> bombs out because now the DBGrid is referencing columns that don't 
> exist, and then I have to recreate the DBGrid columns and resize them 
> again to fit the UI etc.

The same is true in tiOPF, when using mediators:

Listview mediator
     constructor CreateCustom(AModel: TtiObjectList; AView: TListView; ADisplayNames: string; AIsObserving: Boolean = True); reintroduce; overload;
     constructor CreateCustom(AModel: TtiObjectList; AView: TListView; AOnBeforeSetupField: TtiOnBeforeSetupField; ADisplayNames: string; AIsObserving: Boolean = True); reintroduce; overload;

grid mediator:
    constructor CreateCustom(AModel: TtiObjectList; AGrid: TStringGrid; ADisplayNames: string; AIsObserving: Boolean = True); reintroduce; overload;

If the underlying object changes, and ADisplayNames still contains an old property
name, then you get an error as well (or worse, no error, but missing
columns)

In one case you must change the code, in the other, you use the
point-and-click paradigma of RAD to correct things...

> And then there is the matter of having your 
> User Interface layer chock full of business logic because I hooked into 
> the various events of the DB controls, DataSource, ClientDatset.

Business logic should never be in DB controls events, only in field/dataset
events.

> Yes - 
> I've tried to place as much as possible in a Data Module, but it seems 
> I'm fast heading to the same issue I had 15 years ago....
>
>   http://geldenhuys.co.uk/~graemeg/datamodule.png

Using only 1 datamodule is of course doomed to fail.

>
> I've been using tiOPF for so long, I've forgotten what a pain 
> (nightmare) RAD style development can be. Has nobody to this day come up 
> with a simple set of steps on how to implement more maintainable RAD 
> style projects? I have always been told by others that an OPF framework 
> isn't needed, and you can have clean / maintainable RAD style projects 
> with Delphi/Lazarus.... I'm looking hard, but I can't find any such 
> examples, or steps to follow. :-/
>
> Any such help would be much appreciated.

Not sure if it helps, but see

https://www.freepascal.org/~michael/articles/

The series "Large database applications in delphi". 
The strategy described there is used in a set of applications in which 
the main one has over 2000 forms.

Michael.