[VB6] Modulair opzetten of juist niet

[RaZ]

Ik wil een oud project waar ik mee bezig ben geweest, gaan hervatten, maar dit keer van scratch.

Het vorige project was opgezet met functies in aparte BAS-files. Als je dus iets moest editen om er een extra check in te bouwen, was moest je het hele project opnemen, juiste file editen, en de hele applicatie opnieuw compilen.

Hier wil ik dus eigenlijk vanaf.

Ik zat zo te denken, als ik alle functies, die dus nog wel eens verbetered kunnen worden in de toekomst, om deze als DLL's te maken. Heeft er een onderdeel een update nodig, dat ik niet de hele mikmak hoef te compilen.

Ook met oog op dat deze functies ook binnen andere projecten gebruikt kunnen gaan worden. De functies in in een aparte BAS-file mikken in deze meenemen in en ander project kan natuurlijk. Maar dan blijf je alles opnieuw moeten compilen, wat ik dus als negatief ervaar.

De pluspunten van deze opzet die ik wel gaan doen lijken me duidelijk.

Zitten er aan mijn denkwijze mbt op de uitvoering hiervan nog negatieve kanten aan?

[kenneth]

Hoe is alles compileren ingewikkelder, lastiger of moeilijker dan één bestand compileren

Je moet je project logisch indelen, niet op basis van gemak.

[RaZ]

kenneth schreef op woensdag 09 augustus 2006 @ 12:18:
Hoe is alles compileren ingewikkelder, lastiger of moeilijker dan één bestand compileren

Dat heb ik niet gezegt Het is juist makkelijker om 1 keer op de compile knop te drukken dan 30x voor aparte DLL's. Het zal in het begin dus meer werk zijn, maar achteraf makkelijker te onderhouden. Althans, volgens mijn logica dan.

Je moet je project logisch indelen, niet op basis van gemak.

Daarom juist.

Mijn kijk gaat namelijk niet uit naar 1 project, maar ook projecten die ik daarna zal starten. De modulaire insteek is dus dat volgende projecten ook deze DLL's gaan gebruiken. Dus ipv. dat ik een nieuw project start, en daar de BAS-file bij pak, gebruik de DLL's die nodig zijn (hoe dat werkt moet ik nog uitzoeken).

Dus als een functie een update heeft ondergaan hoef ik niet meerdere programma's te compilen, maar enkel de DLL.

Zo zat ik dus ook te denken aan een update-programma. Deze kijkt naar de versie van de DLL's en zal op basis daarvan vervangen kunnen worden door nieuwe, zonder meerdere projecten opnieuw te compilen.

[kenneth]

Ahso, je kan in VB6 natuurlijk niet meerdere projecten in één Solution zetten

Maar het is inderdaad handig om gewoon de DLL's erbij te pakken ipv steeds de sources.

Maar je zal bij een update nog wel moeten kijken of alles nog werkt,

[Boss]

Hoeveel tijd kost het compilen bij jou dan wel niet als je het als hinderlijk ziet?

Is dat VB-eigen? In Delphi kost het compilen van een project met ongeveer 10 modules en een paar duizend regels code echt zelden meer dan 2 seconden. Niet echt hinderlijk.

[kenneth]

Het zit hem niet in de tijdsduur, maar in het aantal projecten dat afzonderlijk gecompileerd dient te worden, begrijp ik.

[Verwijderd]

kenneth schreef op woensdag 09 augustus 2006 @ 13:39:
Ahso, je kan in VB6 natuurlijk niet meerdere projecten in één Solution zetten

erm.....dat kan wel. "File" -> "Add Project"
Daarna het hele zooitje als een Projectgroup opslaan

[RaZ]

Als ik 3 projecten heb, en 4 functies in DLL's, in project1 gebruik ik DLL a & b, in project2 DLL a & d en in project 2 DLL c & b.

Als ik de functie van DLL a ga uitbreiden, hoef ik enkel die DLL aan te passen en te compilen, ipv dat ik project 1 & 2 moet compilen.

Zodoende hoef ik me dus geen zorgen te maken, of bij te houden welke apps er geupdate hoeven te worden.

Dat is dus mijn insteek.

[Boss]

Ah, het gaat dus om hergebruik van je classes / functies. Dan is een DLL wel makkelijk ja, als de situatie het toelaat.

[Verwijderd]

RaZ schreef op woensdag 09 augustus 2006 @ 12:14:
Ook met oog op dat deze functies ook binnen andere projecten gebruikt kunnen gaan worden. De functies in in een aparte BAS-file mikken in deze meenemen in en ander project kan natuurlijk.

Niet om het een of andere, maar kan dit wel?
Ik dacht altijd dat je wel classes in DLL's kon benaderen, maar geen modules...

[RobIII]

Ik zie de hele discussie niet zo. Natuurlijk is het makkelijker als je een shared DLL hebt waarvan meerdere projecten gebruik maken om dan enkel die te hoeven updaten. Je kunt in VB6 prima een projectgroep aanmaken en zo je project compilen debuggen. Ik kan zo niet eens een nadeel bedenken van losse DLL's, zolang je maar zorgt dat je functionaliteit logisch groepeert in de juiste classes en DLLs.

Er zijn wat "beperkingen" in classes in VB6, maar niet genoeg om daarvoor geen losse DLLs te gebruiken. Behalve dat 't misschien een tikkie meer werk is dan alles in een module te flikkeren zie ik er dus uberhaupt geen nadeel in, enkel voordeel.

Verwijderd schreef op woensdag 09 augustus 2006 @ 22:00:
[...]

Niet om het een of andere, maar kan dit wel?
Ik dacht altijd dat je wel classes in DLL's kon benaderen, maar geen modules...

TS doelt natuurlijk op het toevoegen van dezelfde .bas-file in elk project en het vervolgens meecompileren in het project. Maar dat houdt dus in dat als je wijzigingen maakt in de .bas dat je ieder project dat die code gebruikt opnieuw moet compileren.

[ Voor 27% gewijzigd door RobIII op 09-08-2006 22:11 ]

[remco_k]

Een groot nadeel van het modulair opzetten van je projecten:

Stel dat je de gegeven parameters van een functie in de DLL aanpast, dan word het pas 'complex', want dan moet je al je projecten langs die deze DLL gebruiken en die eerst daarop aanpassen en dan compilen.
Datzelfde geld overigens ook als je de functie niet in een DLL hebt zitten maar dat had je natuurlijk al door.

Als je dus modulair gaat bouwen is het belangrijk om een functie in 1x goed te bedenken, met name de interface. De interface 'mag' je daarna nooit meer verbouwen.
Moet je dan toch de interface achteraf verbouwen, dan maak je een nieuwe functie in de dll met de nieuwe interface en je laat de oude ongemoeit zitten, zodat je niet onnodige tijd hoeft te verspillen voor het compilen van andere projecten.

Nog een voordeel aan de verkoop zijde van modulair bouwen:
Je kunt een basis pakket met module a,b en c verkopen. De klant kan optioneel d, e en f erbij kiezen. (en dat zijn dan feitelijk d.dll, e.dll en f.dll).

[RobIII]

remco_k schreef op maandag 14 augustus 2006 @ 14:37:
Een groot nadeel van het modulair opzetten van je projecten:

Stel dat je de gegeven parameters van een functie in de DLL aanpast, dan word het pas 'complex', want dan moet je al je projecten langs die deze DLL gebruiken en die eerst daarop aanpassen en dan compilen.

Bull. Je kunt een parameter optioneel maken of beter: een andere functienaam met de nieuwe functionaliteit. Zo hou je je DLL heel simpel backwards compatible.

remco_k schreef op maandag 14 augustus 2006 @ 14:37:
Datzelfde geld overigens ook als je de functie niet in een DLL hebt zitten maar dat had je natuurlijk al door.

Waarom zou je dan al je andere projecten opnieuw moeten compilen, als ze die functie toch niet gebruiken?

remco_k schreef op maandag 14 augustus 2006 @ 14:37:
Als je dus modulair gaat bouwen is het belangrijk om een functie in 1x goed te bedenken, met name de interface. De interface 'mag' je daarna nooit meer verbouwen.

Moet je dan toch de interface achteraf verbouwen, dan maak je een nieuwe functie in de dll met de nieuwe interface en je laat de oude ongemoeit zitten, zodat je niet onnodige tijd hoeft te verspillen voor het compilen van andere projecten.

Je spreek jezelf hier tegen

[Lustucru]

RobIII schreef op maandag 14 augustus 2006 @ 17:41:
[...]
Bull. Je kunt een parameter optioneel maken of beter: een andere functienaam met de nieuwe functionaliteit. Zo hou je je DLL heel simpel backwards compatible.

Ook leuk, want als je dan je nieuwe functionaliteit wilt implementeren in je andere applicaties kun je daar de functieaanroep wijzigen en opnieuw compileren. Lood om oud ijzer dus behalve dan dat je een vuile DLL krijgt met functie, functie_2, functie_3.

De parameter optioneel maken helpt niet: iedere wijziging in je interface levert een nieuwe ID op voor jje component en helpt meteen je referenties naar de verdommenis. Kun je ook alle projecten gaan hercompileren. Linksom of rechtsom, de term DLL-Hell is niet uit de lucht komen vallen.

http://msdn.microsoft.com...patibility.asp?frame=true

[RobIII]

Niesje schreef op maandag 14 augustus 2006 @ 18:38:
[...]


Ook leuk, want als je dan je nieuwe functionaliteit wilt implementeren in je andere applicaties kun je daar de functieaanroep wijzigen en opnieuw compileren. Lood om oud ijzer dus behalve dan dat je een vuile DLL krijgt met functie, functie_2, functie_3.

De parameter optioneel maken helpt niet: iedere wijziging in je interface levert een nieuwe ID op voor jje component en helpt meteen je referenties naar de verdommenis. Kun je ook alle projecten gaan hercompileren. Linksom of rechtsom, de term DLL-Hell is niet uit de lucht komen vallen.

http://msdn.microsoft.com...patibility.asp?frame=true

Daarom ben ik zo voor late-binding Dan heb je dat probleem niet

Ik zeg absoluut niet dat het ideaal is ofzo, absoluut niet. Maar het werkt wél.
Trust me, I know my way around in VB6 en de term DLL-Hell is mij dan ook helemaal niet vreemd

[ Voor 14% gewijzigd door RobIII op 14-08-2006 20:00 ]

[Lustucru]

Als de insteek is om de ontwikkeling van een applicatie te stroomlijnen zou ik late binding toch niet willen aanbevelen. Maar oké, het werkt wel, min of meer.

TS wilde losse DLL's om niet de hele mikmak opnieuw te hoeven compilen bij wijziging in een functie. Dat argument gaat dus alleen maar op als hij of late binding gebruikt of diverse functievarianten in een dll onderhoudt. Als dat het enige argument is geloof ik dat ik dan liever de hele mikmak opnieuw compile.

[RaZ]

Als ik zo naar het commentaar kijk, ga ik niet eens uitzoeken hoe ik DLL's het beste kan doen en hoe ik ze kan gebruiken.

Voor elke functie maakte ik sowieso een apparte BAS-file. Mik ik wel een paar regels als comments neer in welke projecten de betreffende BAS is opgenomen mocht er een verandering plaatsvinden.

Thanx all

[remco_k]

RobIII schreef op maandag 14 augustus 2006 @ 17:41:
[...]
Bull. Je kunt een parameter optioneel maken of beter: een andere functienaam met de nieuwe functionaliteit. Zo hou je je DLL heel simpel backwards compatible.
[...]
Je spreek jezelf hier tegen

Dat is niet tegenspreken, dat is een oplossing bieden door een andere functienaam te gebruiken als je het aantal parameters uit gaat breiden. Precies wat je zelf ook zegt.
En dat is wel een nadeel want je krijgt dan gewoon een beetje een rommelige DLL. Zeg maar gewoon dat het dan op de windows API gaat lijken.
Een functie uitbreiden met een optionele parameter levert (zoals al gezegd) ook problemen op, tenzij je die optionele parameter vanaf het begin erin hebt zitten.
Ik gebruik overigens bij voorkeur altijd late-binding. Dat is even iets meer werk in den beginne, daarna zit je goed. Nooit geen gekl**t meer.

[pjonk]

VB6 kan gewoon binary compatibility garanderen.

Binary Compatibility
VB makes it possible to extend an existing class or interface by adding new methods and properties etc. and yet still retain binary compatibility. It can do this, because it silently creates a new interface ID for the extended interface and adds registration code to register the original interface ID but with a new Forward key containing the value of this new interface ID. COM will then substitute calls having the old ID with the new ID and hence applications built against the old interface will continue to work (assuming the inner workings of the component remain backward compatible!).

With this setting, VB will not change any of the existing class, interface or type library ID’s, however in order that it can do so, VB requires the project to specify an existing compiled version that it can compare against to ensure that existing interfaces have not been broken.

Bron:
http://www.visibleprogress.com/vb_binary_compatibility.htm

Late binding zal ik ten alletijden proberen te vermijden want het zorgt voor een performance hit en je typesafety is ook verdwenen.
Ik heb zelf een Framework in VB6 gebouwd bestaande uit meerdere DLL's OCX'en en ben niet tegen compatibility problemen aangelopen. Helaas is het behelpen met COM aangezien VB6 en ook COM interfaces geen method overloading ondersteunen. De beste keuze is om toch een nieuwe method toe te voegen.