| 

.NET C# Java Javascript Exception

3
Ich habe den Artikel unter http://www.theserverside.net/tt/articles/showarticle.tss?id=ControllingDependencies überflogen und bin mir nicht sicher, ob ich den Vorschlägen folgen soll.

Wie seht ihr das bzw. wie setzt ihr das in euren Projekten um:

- Möglichst nur ein Assembly erstellen und den Code nur durch unterschiedliche Namespaces trennen
oder
- Auch kleinere (logische) Einheiten in separaten Assemblies abbilden

Unabhängig davon:
Wie grenzt ihr die Namespaces/Assemblies voneinander ab: nach Wiederverwendbarkeit, nach Architekturmustern etc.?
01.08.2011
philipp 167 1 7
philipp 167 1 7
3 Antworten
3
Hallo philipp,

auch wenn die Aussage schon furchtbar abgedroschen ist, ich muss es sagen:
"It depends".
Es ist abhängig von vielen Dingen, mit zu den Entscheidenden zählen in meine Augen Projektgröße, Erweiterbarkeit, Wartbarkeit und Testbarkeit.
Für eine Minianwendung mag eine Assembly ausreichend sein, bei einem Wegwerf-Tool auch, eine pluginfähige verteilbare Mehrschichtanwendung werde ich mit einer Assembly aber nicht stemmen.

Ein paar grundsätzliche Ansätze bzw. Aussagen kann ich aber beitragen.

  • Logische Unterteilung in Namespaces macht unabh. von der Anzahl Assemblies immer Sinn
  • Bei einer mehrschichtigen Applikation sind die Schichten heiße Kandidaten für einen Schnitt in mehrere Assemblies
  • Bei komponentenorientiertem Design sind Komponenten heiße Kandidaten für logische Einheiten (die durchaus aus mehreren Assemblies bestehen können)
  • Applikationsinfrastruktur (Logging, Threading, Aspects, ...) kann auch wiederverwendbar in eigenen Assemblies bereitgestellt werden

Um Deine letzte Frage noch zu beantworten: Eine universelle Lösung sehe ich nicht, neben formellen Kriterien spielt hierbei auch die Erfahrung eine große Rolle.
Gruß
Florian
01.08.2011
ffordermaier 8,4k 3 9
2
Zu Florians Aussage ist nicht mehr viel hinzuzufügen.
Ergänzend vielleicht:

  • Aufteilung nach Wiederverwendbarkeit. Ein gutes Beispiel dafür sind z.B. selbstgeschriebene Controls oder andere Utilities.
  • Aufteilung nach Vererbung. Beispiel: In einem Assembly, das von allen Projekten geshared wird werden Interfaces / abstrakte Klassen definiert. Die abgeleiteten Objekte werden in eigene Assemblies gegliedert, z.B. um Referenzen zu externen Libraries nicht im ganzen Projekt zu verteilen.
01.08.2011
puls200 3,8k 7
1
Hallo Philipp,

folgende Vorteile für einzelne Assemblies fallen mir zusätzlich noch ein:


  • Bessere Trennung nach Zuständigkeiten auf MA-Ebene
  • Beim Bereitstellen von Bugfixes hält sich die Größe in Grenzen (evtl. muss nur ein kleines Assembly als Bugfix bereitstellen)
  • Deployment: Hat man verschiedene Programm-Variationen (z.B. light, full) werden einfach weniger Assemblies mit ausgeliefert (PlugIn-Konzept)


Es gibt aber auch Nachteile bei sehr großen Projekten (z.B. >200 Assemblies), bei Dir wahrscheinlich eher irrelevant:


  • Performance: Das Laden von kleinen Assemblies kostet mehr Zeit als ein zusammengefasstes größeres Assembly
    Siehe dazu auch: Prefer single large Assemblies than multiple small assemblies
  • Viele Assemblies fragmentieren den virtuellen Adressraum, dadurch kann es zu OutOfMemory-Exceptions kommen. Aber nur bei wirklich sehr großen Projekten.
02.08.2011
CodeSniffer 1,3k 4 9

Stelle deine .net-Frage jetzt!
TOP TECHNOLOGIES CONSULTING GmbH