Frage zu Architektur-Artikel aus Ausgabe 3.06

[Roger Bieri]

Hallo,
ich schreibe zwar keinen Leserbrief im eigentlichen Sinne (wenn ich den falschen Ordner dafür im Forum genommen habe, könnt ihr meine Nachricht ja verschieben) habe aber eine Frage zu den beiden Architekturartikeln „Adventure Works Cinema“ und „.NET-Komponenten in grossen Geschäftsanwendungen“:

Für schnell-Leser:
Wie passt das Paradigma der „Mehrschichtigkeit“ zu den Konzepten von Komponenten ? „A. Ramisch; ‚.NET-Komponenten in grossen Geschäftsanwendungen’ (Teil 1)“

1. Würde hier jede Komponente (z. B. „Kontakt“ bzw. „Partner“) ihre eigenen Schichten (Data Access Layer) etc. erhalten ?

2. Wäre es vernünftig, „über“ die ‚leere’ Assembly-DLL die nur die Interface-Deklarationen der exportierten Klassen einer Komponente enthält einen Service Access Layer (SAL) zu legen, der die Komponente über Web-Services verfügbar macht ?

PS: Ich möchte es mir an dieser Stelle nicht nehmen lassen, den Autoren und Verlägern mitzuteilen, dass mich die beiden Architekturartikel sehr begeistert haben. Ich freue mich schon sehr, auf die weiteren Ausgabe dieser interessanten Reihe und hoffe noch auf einige Code-Beispiele für die Praxis, evtl. auf der Heft-CD. ;-)

[Andreas Kosch]

Hallo,
ich selbst habe mir bei den mehrschichten Anwendungen (die einen Schwerpunkt meiner täglicher Arbeit bilden) eine sehr pragmatische Herangehensweis angewöhnt. Ich bin davon überzeugt, dass sich niemand einen Gefallen tut, wenn er mühsam versucht, seine Anwendung so aufzubauen, dass sie gut zu einer Theorie (oder Lehrmeinung) passt. Statt dessen betrachte ich ich die verschiedenen Lehrmeinungen als Ideen-Quelle, von denen ich nur das übernehme, was mich im Alltag selbst überzeugt hat. Die Erfahrungen der letzten Jahre haben gezeigt, dass der technische Fortschritt inzwischen so schnell ist (und LINQ macht deutlich, dass sich daran nichts ändern wird), das sich die Entscheidungs-Kriterien des Für und Wider ändern können.
<br>
Es kommt immer auf den Einzelfall an. Wenn es zum Beispiel in einer Three-Tier-Datenbankanwendung (.NET Enterprise Service) mit einer sehr hohen Benutzeranzahl auf minimale Ausführungszeiten ankommt, wird die Datenzugriffs-Schicht auf die so genannten <b>CRUD</b>-Aktionen (C = CREATE; R = READ; U = UPDATE; D = DELETE) optimiert. Da die Aktion R gegenüber C, U und D unterschiedliche Transaktionsanforderungen hat, ist es in diesem konkreten Fall besser, die die Business Logic-Objekte in die beiden Kategorieren R und C+U+D aufzuteilen. Außerdem gibt es ja gemeinsam nutzbare Zugriffswege, so dass die strikte Trennung (Zuordnung) zusätzlich aufgeweicht wird.

&#10