[Abb. 12] Zusammengesetzte Komponenten wie KL entste hen durch Verschmelzung der Assemblies ihrer Teilkomponenten mittels ILMerge.
Der Aufruf von ILMerge zum Erzeugen der zusammengesetzten Komponente KL könnte zum Beispiel so aussehen:
ilmerge /t:library /out:KLi.dll
Ki.dll Lk.dll Li.dll
Sie weisen ILMerge damit an, eine DLL mit Namen KLi.dll zu erzeugen, die sich aus den bisherigen DLLs Ki, Lk und Li zusammensetzt. Kk.dll bleibt außen vor und behält ihren Namen, weil Ki sie referenziert hat und also KLi sie auch weiterhin refe-renziert. Solange Kk.dll nicht auch mit den anderen DLLs zusammengemischt wird, kann ILMerge die Referenz darauf nicht verändern. Der Kontrakt von KL muss daher Kk und nicht KLk lauten. Das ist schade, doch derzeit nicht zu ändern. Aber ich arbeite an einem Tool, das auch dieses Problem behebt. Mehr dazu in einer zukünftigen dotnetpro. Bis dahin sollten Sie trotzdem nicht auf die Möglichkeit verzichten, Komponenten mit ILMerge zu schachteln. Der Gewinn an Modell-Implementierung-Übereinstimmung ist groß genug, um den Aufwand zu rechtfertigen und diese kleine Unschönheit zu verschmerzen.
Seien Sie einfach konsequent in der Projektplanung und -organisation:
Zerlegen Sie Ihre Applikation zuerst in Betriebssystemprozesse. Das sollte nicht so schwer sein.
Zerlegen Sie dann die Prozesse schrittweise in Komponenten. Immer eine Abstraktionsebene nach der anderen. Sie können dabei top-down oder bottom-up oder - nach Jojo-Manier - wechselweise vorgehen. Am Ende wird der Prozess und so Ihre ganze Anwendung aus mehreren Abstraktionsebenen bestehen. Sie haben mindestens eine Prozessebene und eine Ebene mit Blattkomponenten. Dazwischen können beliebig viele weitere Ebenen mit zusammengesetzten Komponenten oder "Superkomponenten“ liegen.
Für jede Blattkomponente setzen Sie eine Komponentenwerkbank auf, also eine Visual-Studio-Projektmappe, in der Sie fokussiert und isoliert die Komponente implementieren können.
Und für jede zusammengesetzte Komponente tun Sie dasselbe - siehe das Projekt composites/KLi auf der Heft-CD und in Abbildung 13. Auch wenn darin dann kein neuer Implementierungscode steht, manifestieren Sie dadurch doch zumindest das Modell in Code. Das Superkomponentenprojekt dient in diesem Fall dann nur dazu, die Implementierungen der eingeschachtelten Komponenten zusammenzuziehen und zu verschmelzen. Die Werkbank repräsentiert die Integration und kann mit eigenen Tests ausgestattet werden.
[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
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
