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.?

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

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.
  

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.