technischer hintergrund, dlls
-
hallo, ich hätte mal ein paar fragen zur allgemeinen Funktionsweise einer Klassenbibliothek(*.dll) in visual c#. Nehmen wir folgenden fall an: ich schreibe eine konsolenanwendung, und die Klassen mit funktionen der Anwendung pack ich in eine Klassenbibliothek, die ich zum projekt hinzufüge. Wenn ich jetzt diese anwendung starte, was passiert dann? das programm wird in den arbeitsspeicher geladen (ich lasse das JIT-Zeugs mal weg, und vereinfache es, so wie es bei c++ auch ist). Was passiert nun? wird die Dll sofort wenn ich die anwendung starte mit in den Arbeitsspeicher geladen, oder erst, wenn ich eine funktion aus dieser bibliothek brauche? Lohnt es sich bei ner kleinen bis mittelgroßen anwendung, dateien zu gruppen zusammenzufassen, und auszulagern? oder soll man die klassen/funktionen im programm einbinden und z. b. in einem eigenen namespace erstellen?
-
franki84 schrieb:
Was passiert nun? wird die Dll sofort wenn ich die anwendung starte mit in den Arbeitsspeicher geladen, oder erst, wenn ich eine funktion aus dieser bibliothek brauche?
Meinem Kenntnisstand nach wird sie erst bei erstem Gebrauch nachgeladen(deshalb der JIT-Compiler, der erst zur Laufzeit in Maschinencode übersetzt).
franki84 schrieb:
Lohnt es sich bei ner kleinen bis mittelgroßen anwendung, dateien zu gruppen zusammenzufassen, und auszulagern? oder soll man die klassen/funktionen im programm einbinden und z. b. in einem eigenen namespace erstellen?
Kommt drauf an wie weitsichtig du entwickelst. Alles ins Programm einzubinden und nur durch eigene Namespaces zu trennen, hilft dir da nicht viel weiter. Ist letztendlich auch nicht der Sinn der Namespaces.
Überlege dir vorher ob evtl. Funktionen entstehen die du mal später in einem anderen Projekt gebrauchen könntest. Diese lagerst du in eine .dll aus(innerhalb einer eigenen .NET Solution). Hat den Vorteil der Wiederverwend- und Erweiterbarkeit. Passend zum Thema informier dich mal über "Contract First Design".Ich hab "früher" auch alles in einer Projektmappe gehabt, und gehe nun bei einigen Anwendungen den leidvollen Weg eine monolithische Anwendung aufzusplitten, möglichst strikt nach dem "Contract First Design" - Gedanken.