[Abb. 13] Bauen Sie in eigenen Projekten zusammengesetzte Komponenten.

      Superkomponenten machen es Ihnen leicht, Ihre Architektur über die Zeit weiterzuentwickeln. Sie können jederzeit Abstraktionsebenen einziehen oder herausnehmen. Wenn Sie bei der Implementierung einer Komponente feststellen, dass es sich eigentlich lohnen würde, daraus mehrere zu machen, dann bleibt sie im Modell erhalten und wird dort nur zu einer Superkomponente. Die Clients und Services merken von der Zerlegung in Teilkomponenten nichts.

      Die Aggregation von Komponenten können Sie übrigens auch mit Drittanbieter-bibliotheken betreiben. Zur Komponente M in Abbildung 11 könnte zum Beispiel noch log4net [5] als Instrumentierungsdienstleistung gehören. Dann könnten Sie die eigentliche Implementierung von M und die log4net-Assembly mit ILMerge zu Mi zusammenschweißen. Die Abhängigkeit der Komponente M von log4net würde so nach außen hin verborgen.

      Falls allerdings log4net von mehreren Komponenten der Anwendung gebraucht wird, dann verbietet sich natürlich das Verschweißen der Bibliothek mit einzelnen. Das würde einem Copy-and-paste auf Quellcodeebene gleichkommen. Eine solche Vervielfachung von Funktionalität ist nicht wünschenswert.

      Sie können aber auch weitergehen und am Ende alle Assemblies der Anwendung zu einer großen Applikations-Assembly zusammenfügen. Dann kann darin auch eine Drittanbieterbibliothek, die von vielen benutzt wird, eingehen. Ich mache das oft, um das Deployment von Memorystick oder CD oder per Email einfach zu halten. Dann "backe“ ich Anwendungs-Assem-blies und Infrastruktur zu einer einzigen EXE-Datei zusammen. Das funktioniert ohne Probleme.

      Wenn ich also dafür plädiere, Anwendungen während der Entwicklung in viele kleine Assemblies zu zerlegen, die das Modell eins zu eins widerspiegeln, dann bedeutet das nicht notwendigerweise, dass Sie auch all diese Assemblies genau so ausliefern müssen. Mit ILMerge können Sie quasi beliebige Komposite daraus zusammenschmelzen. Die Zahl der Assemblies für das Verteilen kann also viel kleiner sein als die Zahl der Assemblies während der Entwicklung. Der Gewinn: einfaches Deployment und flexible, produktive Entwicklung. Wie es weitergeht mit mehr Regeln und Konventionen, verrate ich Ihnen in der nächsten dotnetpro. [jp]

      [1] Wikipedia: Scrum, QdnpLink SL0806Kolumne1

      [2] Krick Modelltechnik, www.krick-modell.de

      [3] DATS2/BATSLite DAO/ORM Library, QdnpLink SL0806Kolumne2

      [4] ILMerge, QdnpLinkSL0806Kolumne3

      [5] log4net, QdnpLink SL0806Kolumne4