Falls sich die API in der Geschäftslogik ändert, muss man in der obigen Abbildung Änderungen an Component1 und Component2 durchführen.

Mit einem Business Delegates Objekt muss bei Änderungen in der API der Geschäftslogik, Änderungen nur in im Business Delegates Objekt machen.

Verwende Business Delegate falls

• Die Objekte der Präsentationsschicht haben primär zwei Aufgaben
• Die Benutzungsoberfläche zu managen
• Zugriff auf die Geschäftslogik
• Der Code der die Benutzungsoberfläche repräsentiert nicht abhängig von der Geschäftslogik sein soll.
• Mehrere Komponenten der Präsentationsschicht dieselbe Sequenz von Aufrufen an die Geschäftslogikschicht haben.
• Es wird erwartet dass sich die API der Geschäftslogik ändert.

Vorteile:

• Entkoppelt Präsentationsschicht und Geschäftslogikschicht
• Kann als Proxy für den Client verwendet werden, und reduziert damit die Netzwerkbelastung
• Cacht Ergebnisse und Verweise der Geschäftslogik
• Vereinfacht als Fassaden Objekt die Schnittstelle zur Geschäftslogikschicht
• Kapselt den Zugriff auf die Geschäftslogikschicht.

Verwende das MVC Pattern falls

• Es 3 verschiedene Arten von Aufgaben gibt
• Die Interaktion des Benutzers mit dem System zu verwalten
• Die darzustellende Information zu verwalten.
• Diese Information soll unterschiedlich dargestellt werden
• Eine Komponente die all diese Aufgaben erfüllt, kann in 3 kleineren voneinander unabhängigen Komponenten aufgespaltet werden.

Die Komponenten

Das Model ist für die darzustellenden Informationen zuständig. Es persistiert diese Information. Das Model ist unabhängig von den Controllern und den Views. Das Model informiert die Views falls sich die Daten geändert haben. Da das Model seine View i.a. nicht kennt, geschieht dies durch das Beobachter Pattern. Wichtig ist dass die View sehr wohl sein Model kennt, das Model aber nicht die Views.Dies ermöglicht dass mehrere Views auf dasselbe Model zugreifen. Es ist aber nicht möglich, dass eine einzige View mehrere Models hat.

Die View ist für die Darstellung der Informationen zuständig.

Der Controller nimmt die Eingabe des Anwenders entgegen, bearbeitet das Modell und sorgt für die Aktualisierung der Anzeige. Controller und View arbeiten sehr eng zusammen. I.a. gibt es zu einer View genau einen Controller. Es kommt in der Praxis selten vor, daß nur der Controller ausgetauscht wird. Eine sinnvolle Anwendung wäre z.B. von einem editierbaren in ein nicht editierbaren Modus zu wechseln. In der Praxis sind meist Controller und View nicht getrennt und bilden eine Einheit. Diese Trennung zwischen View und Controller ist auch nicht so wichtig, wie die Trennung des Models von der View.

Vorsicht Missverständnis

Was die Rolle des Controllers und View betrifft gibt es einige Missverständnisse in der Literatur. Manche sehen in dem Controller ein Bindeglied zwischen Model und View. Die eigentliche Verarbeitung der Interaktion wird in dieser Literatur der View zugesprochen. Die Aufgabe des Controllers wird dann fälschlicherweise mit der Instantiierung des Models, oder Zuordnung des Models zu einer View zu erstellen. Der grosse Unterschied zum klassischen MVC Pattern liegt dann darin, dass es einen einzigen Controller zu mehreren Views gibt. Im klassischen MVC Pattern hat jede View seinen eigenen Controller. Der Controller der fälschlicherweise in der Literatur unter dem MVC Pattern angegeben wird, ist aber eine andere Art von Controller.

Vorteile des MVC Pattern

• Trennt die Darstellung von Information gegenüber der Verarbeitung
• Erleichter es veschieden Views einzusetzen, oder einfach die View auszutauschen.