Das Model View Controller (MVC) Pattern wurde ursprünglich unter Smalltalk
entwickelt und beschreibt ein allgemeines Prinzip beim Aufbau von grafische
Benutzeroberflächen. Die Kernidee ist die Trennung der Fachklasse von seiner
Darstellung.
Das Pattern besteht aus drei Komponenten
- Model - die eigentliche Fachklasse
- View - Darstellung der Informationen der Fachklasse
- Controller - Benutzerinteraktion
Der Vorteil dieses Aufbaues besteht darin,
dass die Fachklasse komplett von seiner Darstellung entkoppelt ist. Somit
kann die Darstellung der Informationen aus der Fachklasse beliebig geändert
oder erweitert werden, ohne das an der Fachklasse Änderungen vorgenommen
werden müssen. Denkbar ist es auch, mehrere Darstellungsformen zu haben.
Die Trennung von Darstellung (View)
und der Benutzerinteraktion (Controller) dient ebenfalls der Flexibilität.
So kann ein Controller für unterschiedliche Darstellungen verwendet werden.
Nun bleibt nur noch die Frage, was das
alles mit Lotus Notes zu tun hat. Nachdem ich in meinem letzten Blogeintrag
OOP in LotusScript
- Warum sollte man? erklärt habe, warum objektorientierte Programmierung
in LotusScript eine gute Idee ist, will ich nun aufzeigen, wie die Integration
von Fachklassen aussehen kann.
Das primäre Designelement, um Informationen
in Lotus Notes anzuzeigen und zu editieren, ist die Maske. Insofern gilt
es, von der Maske aus auf die in LotusScript geschriebene Fachklasse zuzugreifen.
Allerdings bin ich kein Freund davon, viel Code in der eigentlichen Maske
zu schreiben. Dadurch dass man in einer Maske an diversen Stellen Code
hinterlegen kann, ist es schwierig, den Überblick zu behalten. Deshalb
sollte der relevante Code in einer ScriptLibrary sein. In der Maske befinden
sich dann nur noch die Aufrufe.
So langsam kristallisiert sich das Model
View Controller Pattern für Lotus Notes heraus. Die Fachklasse ist das
Model. Die Darstellung der Information erfolgt über die Maske, die somit
den Teil der View-Komponente übernimmt. (Nicht Notesview sondern rein konzeptionell).
Die Interaktion zwischen den beiden Komponenten übernimmt eine Controllerklasse.
Wozu wird die Controllerklasse benötigt?
Warum nicht direkt von der Fachklasse auf die Maske zugreifen? Das ist
zwar theoretisch möglich, beraubt uns aber der Flexibilität. Insbesondere
wenn in der Fachklasse UI-Methoden verwendet werden würden, könnte man
sie nicht mehr innerhalb von Agenten verwenden, die zeitgesteuert auf dem
Server laufen. Die Controllerklasse sorgt dafür, dass alle notwendigen
UI-Methoden zur Verfügung stehen und trotzdem die Fachklasse in allen denkbaren
Kontexten verwendet werden kann.
Mehr über die Trennung von Backend und
Frontend und die Verwendung der Controllerklasse in meinem nächste Blogeintrag:
OOP in LS: Verwendung von Controllerklassen
/ Trennung von Frontend und Backend
