[Delphi] Modulestructuur in je app bouwen

[OZ-Gump]

Momenteel ben ik bezig met een stukje software dat straks commercieel ingezet moet kunnen worden. Om de diverse klanten de keuze te kunnen geven tussen wat ze wel en niet willen gebruiken wil ik graag in modulestructuur gaan werken. Dat wil zeggen een basisapplicatie met diverse optionele module's. Wat is nou de beste structuur om zoiets op te zetten? Zet je alles (alle code etc.) in je applicatie en werk je met ini's (of reg-entry's of een serial) of is het wellicht verstandiger om de verschillende functionaliteiten allen in DLL's te bakken en die al dan niet te distribueren naar gelang de keuze van de klant?
Ikzelf neig erg naar de laatste optie, maar ik heb eerlijk gezegd niet echt een idee hoe ik bijvoorbeeld menukeuze's uit een DLL kan peuteren om die in de hoofdapplicatie te gaan gebruiken.

Zowel Google, Google-groups als de search van GoT leveren geen antwoord op deze vraag, vandaar deze post.

[whoami]

De menu-opties die de klanten niet willen gebruiken kan je hidden zetten. Dit kun je doen door ergens bij te houden welke opties er moeten getoond worden, de rest verberg je.
Ik zou het niet in ini's gaan bijhouden, gewoon om de simpele reden dat je klant er dan zelf kan in gaan kl*ten. De registry is al iets minder toegankelijk, maar iemand met een beetje kennis van zaken zal dat misschien ook wel vinden.

[OZ-Gump]

De registry is al iets minder toegankelijk, maar iemand met een beetje kennis van zaken zal dat misschien ook wel vinden.

Dat idee had ik dus ook al. Is het misschien een idee om een algoritme te bedenken voor een serienummer (en uiteraard een DLL maken waarin je dat serienummer controleert tijdens de install) en er dan voor zorgen dat dat serienummer bepaalt wat wel en niet zichtbaar is...?

[LordLarry]

Ik zou wel voor losse modules gaan ipv alles wel me te leveren maar via een constructie te verbergen. Het is veiliger en geeft meteen andere voordelen. Zou is het makkelijker werken voor een groep programmeurs als ieder aan z'n eigen stukje werkt. Ook maakt dit het mogelijk extra functionaliteit toe te voegen zonder te recompilen en een nieuwe versie uit te brengen. En als laatste is het een voordeel dat nadat er een bug opgelost is of een nieuwe feature ingebakken niet het complete pakket opgestuurd hoeft te worden, maar dat een klein onderdeel daarvan volstaat.

Je zou de DLL een functie kunnen geven waaraan je een TMenu of TMenuItem meegeeft en waar de DLL dan zelf items toevoegd. Of iets universeler, een functie die aangeeft welke items ie graag zou willen toevoegen en laad de schil de items toevoegen waar het wil.

Vergeet ook COM niet als plugin/module structuur. Of Borland Packages ipv simpele DLL's.

[Verwijderd]

Je zou ook een code en dll's (oid) kunnen nemen. Op die manier voorkom je dat je klanten straks ieder (ze kennen elkaar toevallig) de helft van de modules kopen en dan even een wederzijdse aanvulling doen. Op die manier hebben ze allebei het volledige pakket voor een stuk lagere prijs. Is natuurlijk niet zo legaal, maar omdat ze het programma wel legaal hebben wordt het wel erg lastig checken op illegale software.

[Verwijderd]

Ikzelf heb iets dergelijks in het verleden met DLL-s opgelost idd, is de handigste oplossing imo.

Zoek ook even op 'delphi dll shared memory' bij deja, voor wat meer info over het delen van gegevens etc tussen DLL en applicatie.

[LordLarry]

Verwijderd schreef op 10 December 2002 @ 14:56:
Zoek ook even op 'delphi dll shared memory' bij deja, voor wat meer info over het delen van gegevens etc tussen DLL en applicatie.

Als je Borland Packages gebruikt heb je daar (en ander dingen) geen last van.

[OZ-Gump]

@LordLarry: op delphi.about.com heb ik het een en ander gevonden over het werken met packages en hoe je daar onder andere forms in kunt stoppen. Volgens mij moet ik nu wel een heel eind kunnen komen met die packages.
Dank voor de reacties, ben alweer iets meer 'verlicht'... Ik heb in ieder geval een idee waar ik moet/kan^* zoeken.

_{* Omcirkelen wat van toepassing is}