Dos und Don’ts: Webdynpro Kontext.

Es scheint mir, dass diese Regeln auf Leistungsverbesserung abzielen.

Ich habe einige Bemerkungen zu ein paar dieser Regeln:

• Erstellen Sie bei Bedarf lokale Kontexte, z. B. in Ansichten

Der Komponentencontroller ist Ihr zentraler Hub für Ihren Kontext. Wenn Sie zu irgendeinem Zeitpunkt über einen Kontextknoten verfügen, der für mehrere Ansichten freigegeben ist, sollten Sie den Knoten im Komponentencontroller erstellen und anderen Ansichten zuordnen.

Knoten, die für eine bestimmte Ansicht spezifisch sind, können direkt im Ansichtskontext erstellt werden, aber aus Gründen der Lesbarkeit und Einheitlichkeit zentralisiere ich häufig alle meine Kontextknoten und Bereitstellungsmethoden im Komponentencontroller.

• Verwenden Sie Singleton-Knoten, wenn Verschachtelungen (Master-Knoten) erforderlich sind

Singleton-Knoten sind gut für die Leistung, da Sie nur eine Instanz Ihres Knotens im Speicher behalten, anstatt mehrere Instanzen für jedes (inaktive) übergeordnete Objekt zu haben. Sie wissen jedoch besser, was Sie tun, wenn Sie in die Situation kommen, in der Sie mehrere aktive übergeordnete Elemente benötigen (Zeilenverstärker, verschachtelte Tabellen, Bäume, Mehrfachauswahltabellen…) der Singleton-Knoten gibt Ihre Anwendung aus.

Wenn Sie das Prinzip der Singleton-Knoten nicht gut kennen oder wenn die Leistung kein Problem darstellt, verwenden Sie keine Singleton-Knoten.

• Verwenden Sie keine dynamischen Attribute (IF_WD_CONTEXT_NODE_INFO->ADD_ATTRIBUTE)

Wenn Sie statisch definierte Kontextattribute verwenden können, verwenden Sie statische Attribute. Es wird jedoch Situationen geben, in denen Sie Ihren Kontext dynamisch erstellen müssen. In diesen Fällen haben Sie keine andere Wahl, als dynamische Attribute hinzuzufügen. Ich stimme jedoch zu, dass Sie die dynamische Kontextprogrammierung (und die dynamische Ansichtsprogrammierung) so weit wie möglich vermeiden müssen.

• Verwenden Sie Daten mit Kontextstruktur für BIND_TABLE

Intern verwenden die Bindungsoperationen eine Verschiebungsvariable und behalten die ursprüngliche Tabelle in einer Schattenvariablen bei. Obwohl der Umzug-es ist angeblich schlecht für die Leistung. (Ich sage nein, weil ich Tests von mir selbst gemacht habe und keinen signifikanten Unterschied finden konnte)

• Aktualisieren Sie den Kontext nur, wenn die Daten tatsächlich aktualisiert werden müssen

Hängt davon ab, was Sie mit Update meinen?

• Erstellen Sie keine langen Kontextzuordnungsketten.

?

• Verwenden Sie die Kontextänderungsprotokollfunktionen, um Benutzereingaben zu erkennen. Dies hat besondere Leistungsvorteile, während ein Benutzer der Anwendung nur eine kleine Datenmenge in einer Ansicht ändert, während eine große Menge gemischter Daten angezeigt wird.

Wahr. Das Kontextänderungsprotokoll kann sehr leistungsfähig sein, wenn es dynamisch verwendet wird.

Aber es ist auch sehr weit fortgeschritten. Ich habe ein Snippet, um alle Änderungen in einem Kontext durchzugehen, die Daten der entsprechenden Variablen in der Hilfsklasse zuzuweisen (Feld in der Struktur oder Feld in einer Zeile in einer internen Tabelle) und dynamisch eine Handlermethode aufzurufen (falls vorhanden). Ich habe dieses Snippet mit vielen hochqualifizierten Entwicklern geteilt. Bis heute haben nur 2 tatsächlich verstanden, was es tat, und waren in der Lage, es auf ihre eigenen Komponenten anzuwenden.

Die Regeln, die Sie erwähnen, sind interessant genug, aber wie Steve erwähnt, möchten Sie vielleicht den Zweck und die zugrunde liegende Idee näher erläutern.

Prost!