Hi,
ich hab jetzt am Wochenende intensiv über die Frage nachgedacht und gecoded, wie man sich ein Framework für den Zugriff aus Swing auf Domino aufbaut.
Soweit bin ich ganz zufrieden. Vom Arbeitsstil möchte ich für die Zukunft alle Domino-Operationen (Daten holen, neue Daten schreiben, etc.)
1. im framework realisieren und testen.
2. die gui dran-pflanschen.
Frage: Besteht Interesse an einem solchen Framework? Wenn ja würde ich mir die Mühe machen eine Simpel-Implementierung zu coden und UML-Diagramme zu zeichnen. Es ist sicher nicht der heilige Gral und ich hab festgestellt, dass ich z.b. eine ziemliche Lusche hinsichtlich eines eigenen Exception-Frameworks bin (werd dran arbeiten).
Das Zwischen-Ergebnis ist nun
<mag_chinesisch_klingen_hat_aber_ernsten_hintergrund>
ein Gebilde, das sehr nahe an dem klassischen EJB Pattern Facade liegt. Die Anfragen der GUI Models-Klassen gehen gegen genau eine Facade-Klasse, die als Singleton implementiert ist. Die Facade-Klasse cached Stati-Informationen (ist zwar nicht technisch, aber von ihrer OO-Funktion quasi genau wie eine statefull Session Bean). Die Facade ist relativ eng mit der Klasse NotesConnection (noch ein Singleton) gekoppelt. Alle Notes-Operationen werden von NotesConnection erledigt. Notes-Connection ist zwar nicht technisch, aber von ihrer OO-Funktionalität wie ein Entity Bean (Bean Managed Persistence).
In der Facade-Klasse gibt es für jeden Business-Fall eine Methode. Faktisch existiert in der Klasse NotesConnection genau 1 Methodenaufruf für jede Business-Methode aus der Facade-Klasse. Die NotesConnection erzeugt eine Value Object Klasse (Daten Informationen mit setter/getter). Die Value-Objects sind temporäre Objekte und wenn eine Sammlung an Daten (NotesDocumentCollection) angefordert, werden die Value Objects java.util.Set-Klassen (sortiert faktisch als ArrayList) gepackt. Diese Daten werden dann von der NotesConnection-Methode an die Facade-Business-Methode zurückgegeben, dort findet ggbfls ein post processing statt (Stati in Facade evtl. ändern) und schlußendlich dann an die Gui Swing Models (initial callers) zurückgegeben.
Exceptions werden in eigene Exception-Klassen gepackt.
Recoverable exceptions sollen in der Facade verarztet werden. Nicht heilbare Exceptions werden an die GUI weitergeleitet.
</mag_chinesisch_klingen_hat_aber_ernsten_hintergrund>