OOP in LS: Verwendung von Controllerklassen / Trennung von Frontend und Backend

von Bernd Hort,
assono GmbH, Standort Hamburg,

Mein letzter Blogeintrag OOP in LS: MVC in Lotus Notes hörte mit dem Versprechen auf, näher auf die Trennung zwischen Frontend und Backend und die Verwendung von Controllerklassen einzugehen.

Das zugrundeliegende Ziel bei der Verwendung von Controllerklassen, um auf die Fachklassen zuzugreifen, ist die Umsetzung aller fachlichen Anforderungen nur an einer Stelle im Code.
A picture named M3

Wenn also die fachliche Anforderung z.B. gewisse Pflichtfelder vorzieht, so wird die Definition der Pflichtfelder nur in der Fachklasse vorgenommen. Der entscheidene Vorteil in diesem Vorgehen besteht in einer höheren Wartbarkeit. Wenn sich die Anforderungen mal ändern sollten (was ab und zu mal vorgekommen sein soll wink.gif), dann wird die neue Anforderung auch nur an einer Stelle umgesetzt.

Der Vorteil wird spätestens dann deutlich, wenn neben dem Notes Client auch Eingaben per Web Browser erfolgen. Die Praxis hat gezeigt, dass für eine optimale Umsetzung zwei Masken notwendig sind. Nur so kann in beiden Welten eine optimale Darstellung gewährleistet werden. Statt nun zu versuchen, die Eingabevalidierung in beiden Masken gleich zu halten, greifen die Masken über ihre jeweiligen Controllerklassen auf die Fachklasse zu.

Es muss unterschiedliche Controllerklassen für den Notes Client und den Browser geben, weil in beiden unterschiedliche Events gibt, auf die mit einem Zugriff auf die Fachklasse reagiert werden muss. Zum Beispiel kann bei der Eingabevalidierung im Notes Client beim QuerySave-Event die Gültigkeit überprüft werden. Im Web Browser gibt es zwar mit dem OnSubmit-Event in JavaScript auch ein Event, dass vergleichbar dem QuerySave ist. Jedoch kann dort nicht direkt LotusScript ausgeführt werden. Außerdem kann JavaScript im Browser abgeschaltet sein, so dass man um eine weitere Überprüfung auf dem Server nicht herum kommt.

Selbstverständlich gelten die Anforderungen aus der Fachwelt auch dann, wenn z.B. ein Dokument durch einen zeitgesteuerten Agenten verändert wird. Der Agent greift direkt auf die Fachklasse direkt zu. In dem Fall kann auf einen Controller verzichtet werden, weil es keine Events gibt, auf die reagiert werden müsste.

Damit die Fachklasse von jedem Kontext aus verwendet werden kann, dürfen keine Notes UI-Methoden oder -Klassen wie z.B. NotesUIWorkspace oder NotesUIDocument verwendet werden. Der Grund für diese Einschränkung liegt darin, dass z.B. zeitgesteuerte Agent und WebQuerySave-Agents nicht ausgeführt werden, wenn Notes UI-Klassen im Code referenziert werden. Der Verzicht auf Notes UI-Klassen in der Fachklasse ist insofern keine Einschränkung, weil die Controllerklasse für den Notes Client alle Aufgaben übernimmt, die mit diesen Klassen zu tun haben.

In den nächsten Blog-Einträge werden Basisklassen für Model und Controller vorgestellt, von denen die konkreten Klassen abgeleitet werden können.

Fachbeitrag Entwicklung

Sie haben Fragen zu diesem Artikel? Kontaktieren Sie uns gerne: blog@assono.de

Sie wollen eine individuelle Lösung? Kontaktieren Sie uns

Weitere interessante Artikel

Sie haben Fragen? Wir sind für Sie da.

Wenn Sie mehr über unsere Angebote erfahren möchten, können Sie uns jederzeit kontaktieren. Sie können uns auf verschiedene Weisen für eine unverbindliche Erstberatung erreichen:

assono GmbH

Standort Kiel (Zentrale)
assono GmbH
Lise-Meitner-Straße 1–7
24223 Schwentinental

Standort Hamburg
assono GmbH
Bornkampsweg 58
22761 Hamburg

Telefonnummern:
Zentrale: +49 4307 900 407
Techn. Hotline: +49 4307 900 403
Vertrieb: +49 4307 900 402

E-Mail-Adressen:
kontakt@assono.de
bewerbung@assono.de