Das Notes Forum
Best Practices => Diskussionen zu Best Practices => Thema gestartet von: Axel_Janssen am 25.01.04 - 12:29:35
-
Hi,
in OO notiert man best practices der Programmierung /Architektur/Analyse/Design gerne in Form von Design Patterns (Entwurfsmuster).
Hier ist nähere Erklärung:
http://hillside.net/patterns/definition.html
Design Patterns sind eigentlich programmiersprachenunabhängig. Deshalb sind Notes Design Patterns keine Design Patterns sondern Idioms, d.h. Design Patterns ohne Anspruch der Programmiersprachenunabhängigkeit. Die berühmten J2EE Design Patterns sind btw. auch Idioms, da sie stark mit J2EE gekoppelt sind.
Hier ist Beispiel. Ich übernehme die Notationsform von Adam Bien, der ein sehr gutes Buch über J2EE Design Pattern geschrieben hat und ergänze eine Eigenschaft mit dem Namen scope:
Name: Multi-Lookup Pattern
scope Programmierung // Formelsprache // Masken
1. Hintergrund
Dokumente in einer Notes-Datenbank haben oft Beziehungen zueinander. Beispielsweise kommt es oft vor, dass ein Dokument mehrere Werte eines anderen Dokuments (mit den es in Beziehung steht) anzeigen soll.
Dies wird gerne über Lookup-Formeln realisiert.
2. Zweck
Da die Lookupformeln Ressourcen kosten, soll ihre Anzahl möglichst gering gehalten werden.
3. Problemstellung
Wenn mehrere DbLookupformeln in einem Dokument auf das gleiche Dokument referenzieren, kann dies die Antwortszeit des Ladens dieses Dokuments verschlechtern.
4. Anforderungen
Mehrere Lookups sollen - wo möglich - in einem Lookup zu vereint werden.
5. Lösung
Als Ziel des Lookups wird eine versteckte Ansicht "(werte)" mit den referenzierten Dokumenten erstellt. Die erste Spalte (sortiert) zeigt den key, mit dem aus dem referenzierenden Dokument auf die Daten des referenzierten Dokuments eindeutig zugegriffen werden kann.
Die zweiten Werte zeigt alle Feldinhalte, an die das referenzierende Dokument interessiert ist, getrennt durch ein Trennzeichen (das garantiert nicht in den referenzierten Feldinhalten vorkommt). Kandidaten sind ~ oder #.
Die Formel der zweiten Spalte sieht dann so aus:
Feld1 + "~" + Feld2 + "~" + ... + Feldn + "~".
In einem Feld "ergebnis" des referenzierenden Dokument wird gegen diese Ansicht "(werte)" ein Db-Lookup aufgeführt. Nach dem Laden des Feldes "feldAlleWerte" enthält es alle Werte an denen das referenzierende Dokument interessiert ist.
Die Felder des referenzierenden Dokuments enthalten Formeln der Art @Word(feldAlleWerte;i); Das i bezeichnet dabei die Stelle des gesuchten Werts in der Werteliste.
Praxis
wenn ich Zeit hätte würde ich hier jetzt eine nsf-posten.
Das Feld "feldAlleWerte" sollte möglichst weit oben in der Maske des referenzierenden Dokuments stehen, da Notes-Dokumente von links oben nach rechts unten ihrer Maske geladen werden.
Konsequenzen
Vorteile:
- weniger Lookups, schnellere Ladezeit des Dokuments.
- evtl. mehr Übersichtlichkeit in Maske
Nachteile:
- Das Konstrukt bricht, sobald das Trennzeichen doch einmal in einem Feld auftaucht.
-
Gruß Axel
-
Hi Axel,
das mit dem Scope finde ich sehr gut (zumal ich das auch schon so 1994 bei Lotus praktiziert habe...).
Wegen: Das Konstrukt bricht, sobald das Trennzeichen doch einmal in einem Feld auftaucht.
Das kann man wie folgt machen:
Anstelle eines String, der mit "~" verknüpft ist, kann man eine Liste machen. Also
FeldA : FeldB :... : FeldN
Extrahieren dann mit @Subset(...)
i-tes Element
@If(
i = 1;
@Subset(Liste;1);
@Subset(@Subset(Liste;i);-1
)
Probleme hier (wie auch in Deinem Ansatz): Mehrfachwerte in den Feldern + Unterschiedliche Datentypen
Andreas
-
goile Idee! :D Design Patterns für Lotus Notes Entwicklung. Wenn ich Zeit habe, werde ich versuchen, mitzuarbeiten.
-
Mehrfachwerte: Man verwende mehrere Trennstrings (diverse Patterns - diesmal aber in einem anderen Sinne :) )
-
Fällt mir ein, dass zu Design Patterns letztes Jahr jemand ne Session gemacht hat. Ich werd mal die Slides heraussuchen, wenn ich zurück bin.
Ansonsten gefällt mir der Ausdruck Design Patterns eigenrlich schon besser als Best Practices, es sagt eigentlich besser aus, was es wirklich ist und ist nicht wertend. Tatsache ist einfach, dass man sich bei Sprache auf solch einfache Logik nie verlassen kann ... tja .... thats life .... :)
-
Hi Axel,
ich weiß jetzt eigentlich nur wenig mit diesem Thema anzufangen.
Die Gliederung
1. Hintergrund
2. Zweck
3. Problemstellung
4. Anforderungen
5. Lösung
6. Praxis
7. Konsequenzen
für Artikel von Atnotes-Bestpractices finde ich gut, und ich werde zukünftig - so weit möglich - meine neuen Artikel so aufbauen.
Oder verstehst Du unter "Design Patterns" mehr eine Philosophie ?
Oder ist das "Design Patterns" nur ein Mode-Wort, und im Endeffekt steht dahinter nur die Idee, wie man Beiträge gliedern kann?
Also die Gliederung selbst gefällt mir schon mal gut, es wird so alles soweit berücksichtigt, und ist hilfreich für Autoren, um den roten Faden beizubehalten.
Matthias
-
Oder verstehst Du unter "Design Patterns" mehr eine Philosophie ?
Design Patterns möglichst allgemeingültige Lösungen, die sich in einem bestimmten Kontext als effektiv erwiesen haben.
Design Patterns geben diesen Lösungen einen Namen und erleichtern somit die Kommunikation.
Hinsichtlich der Philosophie sehe ich das als genau dasselbe wie best practices an.
Natürlich gibt es rund um dieses Thema eine Menge Philosophie-wa-wa. Architektur ... Alexander ... Entdeckung nicht Erfindung ...
Ich hab das bewusst ausgespart.
Oder ist das "Design Patterns" nur ein Mode-Wort, und im Endeffekt steht dahinter nur die Idee, wie man Beiträge gliedern kann?
Modewort? Die sogenannte Gang Of Four hat das 1995 aufgebracht und viele haben das als effektiv angesehen und übernommen.
Diese Industrie sehnt sich nach den Heiligen Gral und oft wurden Design Patterns auch hinsichtlich ihrer Effektivität überschätzt.
Gerade für best practices finde ich die Gliederungsmethode sinnvoll.
Im Java-Bereich und noch stärker im J2EE-Bereich sind viele Bücher nach dem Design Patterns Prinzip gegliedert. Ich finde es übersichtlich.
Gruß Axel