Wie wiederverwendbaren Klassen am besten in Bibliothek auslagern?

heiho,

es ist so
ich hab diverse kleine controls
eines ist ein eigener graph
dann vier welche TextBox ueberladen und anderen verhalten geben
und dann noch so ein paar weitere kleine sachen

zuerst hatte ich es immer in dem projekt wo ich es verwendet habe
nun kahm es auch so das ich zb die "IntegerTextBox" auch in einer anderen applikation brauchte

da dachte ich mir so - programmier ich doch das alles nicht doppelt
dann hab ich mal geschaut welche controls sich anbieten wuerden in einer extra dll aus zu lagern

nun hab ich eine dll mit verschiedenen kleinen objekten welche ich in bisher sehr wenigen applikationen verwende

ich frage mich gerade

1. wie sollte ich diese "library.dll" am besten benennen ?
2. macht es sinn die ganze library zu referenzieren wo ich doch nur ein einziges control daraus brauche ?
3. sollte cih es weiter einteilen ? bei dem graphen ist es ok denk ich - das sind so einige objekte, nur textboxen hab ich derzeit 4 verschiedene, und listvies 2 usw usf - macht es da sinn es in verschiedene dll's auf zu teilen ?
   3a. wenn ja welche einteilung macht sinn ?

der gedanke kahm mir auch daher - wegen einer einzigen textbox welche eigentlich recht wenig custom code hat eine dll mit so viel zeug inkludieren ? da koennte man gleich einfach den code kopieren und feddich

was meint ihr ?

bisher hab ich es so:

Library.dll (heisst [temporaer] wirklich so)
\Addon*.cs (1 objekt)
\Controls\ColorControls*.xaml;cs (5 objekte)
\Controls\GraphControls*.xaml;cs (9 objekte)
\Controls\GraphControls\Helper*.cs (1 objekt)
\Controls\TextBoxes*.cs[.xaml (4 objekte)
\Controls\ListViews*.xaml;cs (2 objekte)
\Controls\Panels*.xaml;cs** (1 objekt - bisher nicht verwendet)
\Converter****.cs; ... (2 objekte)

die namespaces sind genauso nur ohne Library zuvor

Hallo Mr Evil,

die Fragen, die du dir stellst, stammen aus einer Zeit, wo man wegen Speicherplatz und Laufzeit auf sowas achten musste. Heute kannst du das alles vergessen. Es ist nicht schlimm eine ganze Assembly einzubinden, obwohl mal nur eine Klasse daraus braucht.

herbivore

um das ein wenig zu präzisieren: es ist schlimmer sehr viele assemblys im speicher zu haben als einige wenige aber dafür umso größere.

wir haben das problem das die performance interessanterweise ab einer gewissen anzahl an geladenen assmblies deutlich einbricht und da das .net framework keine möglichkeit bietet assemblies wieder freizugeben, haben wir mit unserem bestehenden konzept ein paar probleme. einige dieser probleme konnten wir durch eine assembly-zusammenführung lösen.

...und da das .net framework keine möglichkeit bietet assemblies wieder freizugeben...

Kann man nicht Assemblies in einer seperaten AppDomain laden und wenn diese entladen wird, wird auch gleichzeitig die geladene Assembly entladen?!?!

Gruß David

um das ein wenig zu präzisieren: es ist schlimmer sehr viele assemblys im speicher zu haben als einige wenige aber dafür umso größere.

Hast du dafür evtl. ein paar Zahlen ab wann sich das wie bemerkbar macht?

Hallo Mr Evil,

1. wie sollte ich diese "library.dll" am besten benennen ?

Das ist Geschmackssache und kommt auf den Kontext an.
Ich würde es so machen, dass alle Projekte einen kontextbezogenen Prefix bekommen. Für berufliche Projekte z.B. den Firmenname. Die Assemblies der verschiedenen Projekte würden dann beispielsweise heißen:

• <Firmenname>.<Projekt1>.dll
• <Firmenname>.<Projekt2>.dll
• ...

Basisklassen, die in allen Projekten verwendet werden können, würden dann in ein Assembly namens <Firmenname>.dll kommen.

Die Benamung kann dann z.B. noch über Abteilungsnamen o.ä. verfeinert werden.

Vielleicht noch ein Vorschlag zur Organisation der Klassen in Namespaces:

Ich würde mir da ganz Konsequent das .Net-Framework zum Vorbild nehmen. Die Klassen dort sind sauber und durchgängig organisiert, da kann man sich gut dran orientieren.

Beispiele:

Alle WPF-Controls kommen nach
<Firmenname>.<Windows>.<Controls>

Alle abstrakten Controls komme nach
<Firmenname>.<Windows>.<Controls>.<Primitives>

Alle Datenklassen nach
<Firmenname>.<Data>

usw...

Ich würde sogar soweit gehen und die Controls welche in den konkreten Projekten erstellt werden in die selben Namespaces packen (Also nach dem Firmennamen nicht nochmal den Projektnamen im namespace aufführen). Das hat den Vorteil, das man alle Controls hat, sobald man <Firmenname>.<Windows>.<Controls> einbindet. Man mus nicht überlegen wo genau das gesuchte control war, und jedesmal unmengen von Namespaces einbinden. Außerdem hat man ja durch die Verwendung des .Net-Frameworks schon ein Gefühl dafür wo welche Klassen zu finden sind. Das heißt, dass man selbst (und vor allem auch andere Entwickler) sich in der Struktu schnell zurecht finden werden.

Schöne Grüße,

Tachyon

Kann man nicht Assemblies in einer separaten AppDomain laden und wenn diese entladen wird, wird auch gleichzeitig die geladene Assembly entladen?!?!

ja, das kann man tun, wenn diese assemblies nicht zu sehr miteinander verwebt sind.... das ganze ist hier recht verworren verwachsen. aber im Prinzip ist das die einzige Möglichkeit assemblies wieder freigeben zu lassen.

die Einschränkungen diesbezüglich sind aber auch nicht ganz ohne. so ist die Kommunikation mit diesen assemblies recht aufwändig und für einige Szenarien nicht geeignet (z.b. wenn man einen or-mapper direkt an den Datenobjekten hängen hat und die assemblies immer nur direkt auf diesen Objekten arbeiten müssen dann hat man große Probleme).

Hast du dafür evtl. ein paar Zahlen ab wann sich das wie bemerkbar macht?

irgendwo habe ich mal gelesen, das Microsoft empfiehlt nicht mehr als 20 eigene assemblies (also frameworkassemblies ausgenommen) in den speicher zu laden. bei uns geht es ab ca. 40 stk (der wert ist schwammig, empirisch und keine absolute. daher möchte ich nun nicht dafür festgenagelt werden. mag sein, das der Inhalt der assembly ebenfalls eine wesentliche rolle spielt) selbst auf den potenten Entwickler Rechnern spürbar in die Performance.