[Delphi] Waarom datamodule gebruiken?

[Verwijderd]

Er wordt altijd gezegd dat je een datamodule moet gebruiken waarop je je db componenten gooit. Mijn vraag is waarom je die dan zou moeten gebruiken.

Ik heb er nu een hele zooi component opstaan en het begint echt een tering zooi te worden. Het voordeel zie ik er ook niet echt van in.

Is het niet gewoon veel beter om ze per form (mdichild) dynamisch aan te maken?

(Ik maak overal gebruik van niet data-aware controls.)

[Verwijderd]

Het handig wat ik van een datamodule vond was dat ik alle query's maar 1x hoefde te maken of te veranderen. En alleen even de datasources te koppelen.
Ook vond ik het wel makkelijk dat ik functies maar 1x hoefde de maken dat mijn de database te maken hadden.

Het voordeel is ook dat je maar 1x een verbinding maakt met je database.
En je geeft je datamodule dan iedere keer door aan het nieuwe form (je maakt de datamodule aan op de onCreate van je main form en sluit em op de onCloseQuery)

[Delphi32]

Ik groepeer meestal. 1 datamodule voor de database connectie, en dan een voor elk business object in mn applicatie. Bij grotere projecten kan ik zelfs gaan splitsen: 1 read-only versie van een business object (alleen maar queries voor lookup-spul enzo) en 1 'edit'-versie waarin ik alles zet wat met editen van een business object te maken heeft. De readonly versie bevat dan o.a. cached queries met ID en omschrijving zodat ik gemakkelijk lijstjes kan samenstellen (lekker snel). Readonly-datamodules worden gecreëerd bij het starten van de applicatie, de edit-datamodules worden on demand geïnstantieerd.

* Delphi32 is overigens fan van het principe 'TDataSource hoort op de TForms thuis en niet in de TDatamodules', maar wil daar hier maar geen discussie over starten

[Verwijderd]

Maar het heeft toch geen nadelen als ik het database component en de default transaction op een datamodule gooi en de rest (query, transaction, procedure) gewoon op de forms?

[Verwijderd]

Het hangt een beetje van je ontwerp en je voorkeur af of je je datasets, etc. op een datamodule zet of niet.
Bij een SDI-applicatie is een datamodule erg prettig, alle niet-visuele componenten op 1 plek, en designtime worden je forms niet zo'n rommel. Maar bij MDI ben ik geneigd om de datasets op de MDIChildren te zetten, omdat je dan ZEKER weet dat een query bv. niet door een ander MDIChild gebruikt wordt.

Als je al die datasets, etc. op je form geen gezicht vindt, dan kun je ze natuurlijk ook dynamisch aanmaken (eigenlijk mijn voorkeur).

Voordeel: De datasets bestaan alleen maar wanneer je ze echt gebruikt, kleinere footprint dus.

Nadeel: Het steeds opnieuw aanmaken en weer destroyen van datasets kost wat tijd, maar meestal is 't niet merkbaar. En wanneer je de fielddefs nodig hebt (voor DisplayLabels of calculated fields bv.) moet je die met 't handje aanmaken. Die fielddefs zijn de enige reden waarom ik zo nu en dan de boel niet runtime aanmaak.

Enne... waar mogelijk hoort m.i. een DataSource in dezelfde module als de DataSet waar 'ie bij hoort. Of dat nou een Form of een DataModule is, doet er niet zoveel toe.

[Tom-my]

Verwijderd schreef op 04 augustus 2002 @ 16:14:
Het hangt een beetje van je ontwerp en je voorkeur af of je je datasets, etc. op een datamodule zet of niet.
Bij een SDI-applicatie is een datamodule erg prettig, alle niet-visuele componenten op 1 plek, en designtime worden je forms niet zo'n rommel. Maar bij MDI ben ik geneigd om de datasets op de MDIChildren te zetten, omdat je dan ZEKER weet dat een query bv. niet door een ander MDIChild gebruikt wordt.

Als je al die datasets, etc. op je form geen gezicht vindt, dan kun je ze natuurlijk ook dynamisch aanmaken (eigenlijk mijn voorkeur).

Voordeel: De datasets bestaan alleen maar wanneer je ze echt gebruikt, kleinere footprint dus.

Nadeel: Het steeds opnieuw aanmaken en weer destroyen van datasets kost wat tijd, maar meestal is 't niet merkbaar. En wanneer je de fielddefs nodig hebt (voor DisplayLabels of calculated fields bv.) moet je die met 't handje aanmaken. Die fielddefs zijn de enige reden waarom ik zo nu en dan de boel niet runtime aanmaak.

Enne... waar mogelijk hoort m.i. een DataSource in dezelfde module als de DataSet waar 'ie bij hoort. Of dat nou een Form of een DataModule is, doet er niet zoveel toe.

Dat vind ik nou ook.

[Delphi32]

Verwijderd schreef op 04 augustus 2002 @ 10:56:
Maar het heeft toch geen nadelen als ik het database component en de default transaction op een datamodule gooi en de rest (query, transaction, procedure) gewoon op de forms?

Het kan, het is toegestaan en het werkt. Dus waarom zou je het niet doen.

Mijn overwegingen in deze:
1. Forms zijn de plekken waar je je data visualiseert. Als je je data retrieval spul op je form plakt, maak je je applicatie logica afhankelijk van je forms. Dat is niet (altijd) gewenst; stel je voor dat je na de Forms-visualisatie ook een web-visualisatie moet/wilt maken. Dan moet je al die datasets ed nog een keer implementeren, met alle gevaren van dien (dubbele code voor eigenlijk dezelfde functionaliteit).
Daarom gaat mijn voorkeur uit naar het scheiden van de data layer en de visualisation layer.

2. Stel je hebt een MDI-Child waarop een combo is te zien waarin je een artikel kan kiezen. Lijstje bestaat uit artikel-id en artikel-omschrijving. Om het lijstje te tonen (middels db-controls of niet) moet de dataset open. Als de dataset op je MDI-Child staat, wordt er voor elke MDI-instantie weer een query uitgevoerd. Bij veel forms en/of lange artikel-lijsten gaat dit de prestatie negatief beïnvloeden. Door de dataset op een datamodule te plaatsen die blijft bestaan (dus los van de MDI-Child) hoef je de dataset maar één keer te openen. Gevolg: nieuwe instanties van het MDI-Child form, of andere forms met eenzelfde lijstje, worden veel sneller geopend.

[Tom-my]

Wat ik overigens net bedacht *tja tis benauwd hier :)*, stel je hebt een stel hele grote queries in je datamodule. Dan heb je natuurlijk een vervelend iets als je die "grote" queries niet veel gebruikt maar wel laat autocreaten in je datamodule. Vervelende onnodige wachttijd in je programma.

[Kool]

FanToom schreef op 04 augustus 2002 @ 17:08:
stel je hebt een stel hele grote queries in je datamodule. Dan heb je natuurlijk een vervelend iets als je die "grote" queries niet veel gebruikt maar wel laat autocreaten in je datamodule. Vervelende onnodige wachttijd in je programma.

Nee hoor, componenten doen niets totdat je ze activeert. Pas als je de query uitvoert gebeurt er iets.

[Verwijderd]

Oke,

Ik ga de query componenten, transaction, enz... gewoon dynamisch aanmaken in de MDI child's en ik gebruik een datamodule voor mijn database component en de default transaction.

[Verwijderd]

TDataSource is een TComponent afgeleide, dus erg licht qua geheugengebruik. Er is dus geen reden om alles op 1 datasource te zetten, je kunt er net zo goed een heel stel maken. TDataSource is gewoon makkelijk design-time, omdat je anders die componenten op een form zou moeten zetten, wat niet erg overzichtelijk is.

Ik maak trouwens bijna al mijn datasources dynamisch aan, als ze nodig zijn. [Net als mijn forms trouwens].