[C#] Assemblies Versus Klassen

[Verwijderd]

Ik ben van plan om in de toekomst software te gaan ontwikkelen in C#. Hierbij zijn er altijd onderdelen die hergebruikt kunnen worden en mijn vraag hierbij is of het nu aan te raden is om voor elk onderdeel, zoals een database connectie onderdeel of een onderdeel om formulieren te genereren een aparte assemblie/dll te maken of gewoon steeds de klasse te hergebruiken?

[whoami]

Een class en een assembly zijn iets geheel anders... Een assembly kan meerdere classes bevatten.
Ik begrijp je vraag niet zo goed, en ik denk dat je een en ander met elkaar verward ?

[Rodyman]

Ik denk dat hij bedoelt of het slim is om bepaalde classes te bundelen in een losse assembly, of dat hij gewoon de klasses gebruikt/kopieert die hij nodig heeft in dat project.

[ThunderNet]

Assemblies zijn onderhoudstechnisch natuurlijk handiger
Heb je een bug in 1 van die klassen, hoeveel je alleen de assembly te fixen.
Heb je een bug in 1 van die klassen, in de andere situatie. Moet je die bug meerdere keren fixen, en alle programma's opnieuw compileren

[Verwijderd]

Hij bedoelt volgens mij het volgende:
- Moet ie elke keer klassen "copy'en" uit zijn huidige projecten
- Of maakt ie assemblies aan met de functionaliteit en stopt die ze in zijn project.

1e is niet te onderhouden wanneer je dezelfde klasse in 100 projecten hebt zitten en er treed een "klein" foutje op in je code.
2e daar en tegen is goed te onderhouden omdat je alles op 1 plek hebt.

Echter niet alles kan je zomaar in assemblies stoppen om het te hergebruiken. Er zullen veel project specifieke zaken zijn die je niet zomaar kan copy'en. Echter je kan wel apparte "systemen" in assemblies stoppen zoals log systemen / error afhandeling noem maar om dit vervolgens in een assembly te stoppen en deze voor al je projecten te gebruiken.

offtopic:
Edit: zie alweer dat ik redelijk laat ben en er al 2 reacties boven mij zijn

[ Voor 10% gewijzigd door Verwijderd op 04-11-2005 14:25 ]

[TeeDee]

@Rodyman: dat denk ik ook.

Wij hebben hier inmiddels een Control/Class library met daarin:
- security (met daarin password hashing, password generators, rollen etc.)
- data access
- een paar custom text fields
- Utility die allerlei SQL meuk checked

Ideaal, voeg de Library toe, en gaan.
Scheelt me in ieder geval behoorlijk wat copy/paste werk.

Ik denk dat het puur je eigen mening zal zijn, maar ik kan haast niet meer zonder.

edit:
</laat>

[ Voor 11% gewijzigd door TeeDee op 04-11-2005 14:26 ]

[Verwijderd]

Dat is inderdaad precies wat ik bedoelde. Het is me nu al een heel stuk duidelijker.

Maakt het kwa performance eigenlijk uit of een klasse nu uit een assemblie komt of niet?

[whoami]

Verwijderd schreef op vrijdag 04 november 2005 @ 14:27:


Maakt het kwa performance eigenlijk uit of een klasse nu uit een assemblie komt of niet?

Een class komt altijd uit een assembly.
Als je die class nu copy/pasted in jouw project (binnen de exe , dan zit ze ook in die assembly (de exe)).
Zit de class in een aparte dll, dan zal het framework natuurlijk eerst die dll moeten inladen. Dat inladen neemt natuurlijk wat tijd in beslag, maar de voordelen die het biedt (utility classes die je in veel projecten nodig hebt, in een aparte assembly steken) zijn veel belangrijker tov dit kleine performance loss.

[Verwijderd]

Cool, bedankt iedereen voor de info!

[.oisyn]

Verwijderd schreef op vrijdag 04 november 2005 @ 14:24:
Hij bedoelt volgens mij het volgende:
- Moet ie elke keer klassen "copy'en" uit zijn huidige projecten
- Of maakt ie assemblies aan met de functionaliteit en stopt die ze in zijn project.

1e is niet te onderhouden wanneer je dezelfde klasse in 100 projecten hebt zitten en er treed een "klein" foutje op in je code.
2e daar en tegen is goed te onderhouden omdat je alles op 1 plek hebt.

2 is nogal kut als je meerdere projecten hebt die van je library gebruik maken, en de library ook doorontwikkelt wordt. Als je door changes in de library bugs krijgt, zijn meteen al je applicaties stuk en unshippable. Ook moet je bij een change in design meteen àl je applicaties aanpassen om het compileerbaar te houden.

En 1 is zelfs heel makkelijk te onderhouden als je gewoon goede source control hebt (en zonder ben je imho gewoon niet professioneel bezig). Je brancht je library naar de verschillende applicaties, en als je dan changes door wilt voeren die stabiel bevonden zijn kun je gewoon integraten naar die andere branches. Ook kun je dan lokaal bugs oplossen per applicatie, en die changes dan weer terug integraten naar de library zodat die bugfixes daar dan ook weer zijn. En bij designchanges in de library kun je op je gemak je applicaties afzonderlijk van elkaar updaten, en voor degene waarvoor het nog niet interessant is blijf je gewoon nog even de oude library gebruiken.

[ Voor 12% gewijzigd door .oisyn op 04-11-2005 16:55 ]

[whoami]

.oisyn schreef op vrijdag 04 november 2005 @ 16:49:
[...]


2 is nogal kut als je meerdere projecten hebt die van je library gebruik maken, en de library ook doorontwikkelt wordt. Als je door changes in de library bugs krijgt, zijn meteen al je applicaties stuk en unshippable. Ook moet je bij een change in design meteen àl je applicaties aanpassen om het compileerbaar te houden.

Je kan in .NET opgeven welke versie van die library een applicatie moet gebruiken; je kunt verschillende versies in de GAC staan hebben, en met behulp van een publisher policy geef je aan welke versie er moet gebruikt worden

[.oisyn]

Right, en hoe ga je ooit bugs fixen in een oudere versie?

[whoami]

Als het louter om 'bugs' fixen gaat, dan denk ik toch dat de interface van die library niet zal moeten aangepast worden. Waarom zouden die bestaande applicaties die oude versie van die lib dan niet kunnen gebruiken ?

[ColdSTone|IA]

.oisyn schreef op vrijdag 04 november 2005 @ 16:49:
[...]
2 is nogal kut als je meerdere projecten hebt die van je library gebruik maken, en de library ook doorontwikkelt wordt. Als je door changes in de library bugs krijgt, zijn meteen al je applicaties stuk en unshippable. Ook moet je bij een change in design meteen àl je applicaties aanpassen om het compileerbaar te houden.

Volgensmij is het niet de bedoeling bij doorontwikkeling de functionaliteit van je library te wijzigen. Als alles netjes gedocumenteerd is zouden er dus geen nieuwe bugs moeten ontstaan. Als je je testsuite netjes op orde hebt, hoeft dit dus niet te gebeuren.

[.oisyn]

whoami schreef op vrijdag 04 november 2005 @ 17:26:
Als het louter om 'bugs' fixen gaat, dan denk ik toch dat de interface van die library niet zal moeten aangepast worden. Waarom zouden die bestaande applicaties die oude versie van die lib dan niet kunnen gebruiken ?

Situatieschets:

Je maakt Library 1.0 met design X. Applicatie 1.0 shipt met library 1.0
Je redesigned Library 1.0 naar Library 2.0 met design Y. Omdat Applicatie 1.0 nog met library 1.0 werkt is ie niet compatible met het nieuwe design
Je ontdekt een nogal kritieke bug in Library 1.0. Applicatie 1.0 updaten zodat hij lib 2.0 kan gebruiken is teveel werk, je wil zo snel mogelijk een nieuwe build releasen. Kun je nu, met de methode die jij beschreef, de source van 1.0 aanpassen en opnieuw compileren? En hoe voer je die changes dan weer door naar opvolgende versies, zodat die bug daarin ook niet meer bestaat?

Het is een probleem dat typisch is op te lossen met een goed sourcecontrol systeem waarin je kunt branchen en integraten.

ColdSTone schreef op vrijdag 04 november 2005 @ 17:37:

Volgensmij is het niet de bedoeling bij doorontwikkeling de functionaliteit van je library te wijzigen.

Wie zegt dat? Waarom zou je je library mogen updaten met een verbeterd design, voor gebruik in toekomstige projecten?

Als alles netjes gedocumenteerd is zouden er dus geen nieuwe bugs moeten ontstaan.

Dit is nogal een nonsense stelling die in de praktijk totaal niet opgaat helaas

Als je je testsuite netjes op orde hebt, hoeft dit dus niet te gebeuren.

Als je je zaakjes netjes op orde hebt, ben je er op voorbereid dat het tóch kan gebeuren, en dat je het bovendien snel kunt fixen

[ Voor 9% gewijzigd door .oisyn op 04-11-2005 17:51 ]

[whoami]

Wie zegt dat? Waarom zou je je library mogen updaten met een verbeterd design, voor gebruik in toekomstige projecten?

Impliceert dat dan dat jouw 'oude' library ineens verdwenen is ? Dat je daar de source niet meer van hebt ?
Als je het hebt over een verbeterd design, dan heb je imho een nieuw 'project'.

[Rolgordijn]

whoami schreef op vrijdag 04 november 2005 @ 18:09:
[...]

Impliceert dat dan dat jouw 'oude' library ineens verdwenen is ? Dat je daar de source niet meer van hebt ?
Als je het hebt over een verbeterd design, dan heb je imho een nieuw 'project'.

Wat nou als er gebruik wordt gemaakt van een iteratieve ontwikkelmethodiek en dat tijdens de doorontwikkeling de interface geëvolueerd is? Het hoeft dus niet perse om een nieuw project te gaan.

[.oisyn]

whoami schreef op vrijdag 04 november 2005 @ 18:09:
[...]

Impliceert dat dan dat jouw 'oude' library ineens verdwenen is ? Dat je daar de source niet meer van hebt ?

Euh nee, maar ik zie de relevantie van wat jij zegt met het stukje dat je quote eigenlijk niet helemaal. Of reageer je op het eerste deel van mijn post? Ik ken die .Net feature namelijk niet echt, het klinkt alsof je gecompileerde libraries onder een versienummer in een assembly hangt. Dan heb je óf maar 1 copy van je library (onwerkbare situatie bij meerdere projecten), namelijk de huidige versie, óf allemaal verschillende copies per versie en dan zit je feitelijk al met de situatie dat elk project zijn eigen copy van de library heeft.

Als je het hebt over een verbeterd design, dan heb je imho een nieuw 'project'.

Natuurlijk niet, het is een library die in meerdere projecten gebruikt gaat worden (tenminste, zo begrijp ik de topicstart), en het ontwikkelen van die producten kan best parallel aan elkaar plaatsvinden. Het kan zelfs zo zijn dat je een apart team op de library hebt zitten. (Dat is bij ons ook het geval, zo hebben we bijvoorbeeld een 3d engine, en elke game heeft zijn eigen lokale branch van die engine. Een bug of een veranderd design geïntroduceert door het engine ontwikkelteam sloopt geen games, en bugs die er al in zaten kunnen als de nood daar is in de game zelf meteen gefixed worden.)