Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Wiederverwendung von Code und Apex-Steuerfelder

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
  • Beschreiben des Unterschieds zwischen Vererbung und Zusammensetzung für die Wiederverwendung von Code
  • Beschreiben der Architektur- und Syntaxunterschiede zwischen Apex-Steuerfeldern von Visualforce- und Aura-Komponenten

Vererbung im Vergleich mit Zusammensetzung

Obwohl wir in einem Intensivseminar zur Softwareentwicklung eine Woche mit diesem Thema verbringen könnten, wollen wir uns kurz fassen.

Aura-Komponenten können von übergeordneten Komponenten erben und, Vererbung ist ein wichtiger Stil bei der Gestaltung von wiederverwendbarem Code. Es gilt jedoch:

Geben Sie der Zusammensetzung gegenüber der Vererbung den Vorrang.

Es ist nicht umsonst vom "Lightning-Komponenten-Framework" die Rede. Die Zusammensetzung ist das grundlegende Modell für die Wiederverwendung Ihres Codes.

Es gibt zwei konkrete Gründe für das Übernehmen dieses Modells.

  1. In der Implementierung des Frameworks zeichnet sich die Vererbung durch wesentliche Leistungsnachteile aus. Bei den Details sind Änderungen vorbehalten, doch Sie werden feststellen, dass bei Verwenden der Vererbung mehr Arbeitsspeicher- und Prozessorressourcen als ggf. erwartet belegt werden.
  2. In Aura-Komponenten funktioniert die Vererbung nicht genau so wie in Apex oder Java, sondern eher...eigenartig.

    Eine untergeordnete Komponente kann beispielsweise aus einer übergeordneten Komponente erweitert werden. Und die untergeordnete Komponente hat z. B. Zugriff auf die definierten Aktionshandler und Hilfsfunktionen der übergeordneten Komponente. Und die untergeordnete Komponente kann diese Handler und Funktionen durch ihre eigenen ersetzen. Doch die untergeordnete Komponente kann diese Handler und Funktionen nicht erweitern.

    Das bedeutet, dass die Hilfsmethode Ihrer untergeordneten Komponente super.aHelperFunction() nicht in ihrer Implementierung von aHelperFunction() aufrufen und dann zusätzliche Logik hinzufügen kann. Sie verwenden entweder die übergeordnete Funktion wie implementiert oder ersetzen sie vollständig. Diese Einschränkung ist ein Dämpfer für die Wiederverwendung. Es gibt eine alternative Vorgehensweise, die einige Verdrehungen mithilfe von <aura:method> umfasst. Diese wird unterstützt und ist leistungsstark, doch wenn Ihr Anwendungsfall einfach ist, fühlt sie sich ein wenig überdreht an.

Die Vererbung wird also in Aura-Komponenten, wie schon gesagt, etwas eigenartig implementiert. Und bei der Implementierung sind Änderungen vorbehalten. Vermeiden Sie komplexe Vererbungshierarchien, damit Sie bei Änderungen am Framework anpassungsfähig bleiben.

Apex-Steuerfelder

Sehen wir uns ein sehr einfaches serverseitiges Steuerfeld an und lassen Sie uns einige Punkte erörtern.
public with sharing class SimpleServerSideController {

    @AuraEnabled
    public static String serverEcho(String echoString) {
        return ('Hello from the server, ' + echoString);
    }
}

Hier fallen einige Dinge auf, so z. B. verschiedene spezifische Unterschiede zu einem Visualforce-Steuerfeld.

  • Die offensichtlichste Neuerung ist die Anmerkung @AuraEnabled. Wenn Sie in Visualforce mit JavaScript Remoting gearbeitet haben, ist dies vergleichbar mit der Anmerkung @RemoteAction, die Sie für diese Methoden verwenden.
  • Die Ähnlichkeit mit JavaScript Remoting setzt sich bei der Methodensignatur fort. Serverseitige Steuerfeldmethoden von Aura-Komponenten müssen static und entweder public oder global sein.
  • Eine Folge davon, dass serverseitige Steuerfeldmethoden static sind, ist, dass Sie den Komponentenstatus nicht auf Serverseite speichern können. Speichern Sie, wie im vorherigen Abschnitt beschrieben, den Komponentenstatus in seinen clientseitigen Attributen.
  • Serverseitige Aktionen geben Daten zurück. Sie können keinen Verweis des Typs PageReference zurückgeben. Implementieren Sie Ihre Navigationslogik auf Client- und nicht auf Serverseite.
  • Rutsche! Etwas, dass ggf. nicht offensichtlich ist, aber Ihnen endlose Kopfschmerzen beschert, wenn Sie es nicht berücksichtigen, ist, dass in der Deklaration von Apex-Methoden verwendete Parameternamen mit den Parameternamen übereinstimmen müssen, die Sie beim Erstellen der Aktion auf Clientseite verwenden.
  • Rutsche! Eine weitere nicht offensichtliche Einschränkung: Geben Sie einer serverseitigen Steuerfeldmethode nicht den gleichen Namen wie einer clientseitigen Aktionshandlerfunktion. Andernfalls können seltsame Dinge passieren. Sie müssen eine Benennungskonvention für Ihre serverseitigen und clientseitigen Methoden befolgen, die die Unterscheidung klar und Namenskonflikte unmöglich macht.

Lassen Sie uns die beiden letzten Aufzählungspunkte wiederholen. Parameternamen müssen beim Übergeben zwischen client- und serverseitigem Code übereinstimmen. Die Methodennamen hingegen müssen nicht übereinstimmen.

Apex im Vergleich mit Aura-Komponenten

Bei allen Aura-Komponenten, die über serverseitigen Apex-Code verfügen, übergeben Sie Daten zwischen JavaScript-Code der Aura-Komponente und serverseitigem Apex-Code hin und her. Die Umwandlungen von Parametern und Ergebnissen zwischen den beiden Datenformaten funktioniert zumeist automatisch. Doch es gibt einige Einschränkungen, die sich auf Ihr Softwaredesign auswirken können.

Apex ist nicht JavaScript

Rutsche! Das mag offensichtlich erscheinen, doch es lohnt sich, darauf hinzuweisen, dass beim Übergeben von Objekten zwischen client- und serverseitigem Code Transformationen der Objekte erfolgen. Ein Apex-Objekt, das ggf. Eigenschaften mit einer komplexen Logik im Hintergrund aufweist, wird bei Rückgabe in Antwortdaten zu einem einfachen JavaScript-Objekt mit ausschließlich Name-Wert-Paaren. Öffentliche Instanzvariablen werden weitergegeben. Öffentliche Getter-Instanzmethoden für das Apex-Objekt werden aufgerufen und in statische Werte aufgelöst, ehe das Objekt serialisiert und zurückgegeben wird. Und so weiter.

Leiter! Wenngleich der Prozess deterministisch und verständlich ist, lohnt es sich häufig, in Apex spezielle, vereinfachte Klassen ausschließlich für das Packen und Zurückgeben von Daten an Aura-Komponenten zu erstellen. Nutzen Sie diese Klassen anstelle Ihrer Verarbeitungsklassen, um Daten zu übertragen.

Das hört sich nach mehr Arbeit (Code) an, was auch stimmt. Doch dadurch wird ein Teil der Komplexität des undurchsichtigen Prozesses der Transformation-Serialisierung-Übertragung-Deserialisierung beseitigt, der erfolgt, wenn Daten von Apex an JavaScript zurückgegeben werden. Durch Beseitigen dieser Komplexität wird das Debuggen vereinfacht.

sObjects

Sie können in JavaScript-Code neue sObjects erstellen, einschließlich benutzerdefinierter Objekte. Es ist ein wenig mehr Syntax erforderlich, die aber übersichtlich ist. Diese sObjects können als Parameter in Anforderungen an serverseitigen Apex-Code gesendet werden. Sie können sObjects in einer Antwort von Apex zurückgeben, woraufhin das Framework sich um die Transformation kümmert.

Benutzerdefinierte Klassen

Leiter! Sie können nicht auf sinnvolle Weise eine benutzerdefinierte Apex-Klasse aus clientseitigem JavaScript-Code an serverseitigen Apex-Code übergeben. Verwenden Sie stattdessen ein einfaches JavaScript-Objekt zum Kapseln der strukturierten Daten des Parameters. Analysieren Sie dieses Objekt wie erforderlich in Ihrem Apex-Code, z. B. im Konstruktor für eine Apex-Klasse.

Sie können eine benutzerdefinierte Apex-Klasse in der Antwort Ihres serverseitigen Steuerfelds an clientseitiges JavaScript zurückgeben. Sie wird jedoch im Rahmen dieses Prozesses serialisiert und deserialisiert, weshalb das Ergebnis ggf. nicht wie erwartet ist. Leiter! Es ist häufig besser, eine Zuordnung mit den Datenelementen, die Sie einbeziehen möchten, oder ein JSON-Element zurückzugeben, das Sie selbst erstellen.

Innere Klassen

Rutsche! Im Code von Aura-Komponenten können Sie keine inneren Apex-Klassen verwenden. Ihr serverseitiger Apex-Code kann sie beim Verarbeiten einer Anforderung nutzen, doch die vom Client zurückgegebene Antwort kann keine Instanz einer inneren Klasse sein.

Vererbung

Rutsche! Sie können mit benutzerdefinierten Apex-Klassen, die Sie in Antworten an Aura-Komponenten zurückgeben möchten, keine Vererbung verwenden.

Behandeln von serverseitigen Fehlern

Leiter! Wenn in Ihrem Apex-Code ein Fehler auftritt, können Sie eine Ausnahme des Typs AuraHandledException erstellen und auslösen. Das Abfangen anderer Ausnahmen, z. B. einer DML-Ausnahme, und ihre erneute Auslösung als AuraHandledException führt auch zu einer wesentlichen besseren Erfahrung auf Clientseite.