Erfassen Sie Ihre Fortschritte
Trailhead-Startseite
Trailhead-Startseite

Kennenlernen von Architekturkonzepten

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:
  • Beschreiben der Paradigmenunterschiede bei Visualforce-Seiten und Aura-Komponenten
  • Erläutern des Konzepts unterschiedlicher Container und der Vorgehensweise zum Einfügen einer Aura-Anwendung oder -Komponente in einen Container

Konzept: Seitenweise Anwendungen im Vergleich zu Einzelseitenanwendungen

Beim Entwerfen einer herkömmlichen, auf Visualforce basierenden Anwendung werden normalerweise eine Reihe von Seiten erstellt und Anwendungsbenutzer navigieren durch Wechseln von einer Seite zur anderen. Man beginnt auf einer Listenansichtsseite, klickt auf den Link zu einer Ansicht, um zu einer Datensatzansichtsseite zu gelangen, klickt auf eine Bearbeiten-Schaltfläche, um zu einer Datensatzbearbeitungsseite zu wechseln, usw.

Aura-Komponenten sind ganz anders. Hier gibt es nur eine "Seite" für die gesamte Anwendung! Wir sprechen hier von "Einzelseitenanwendungen" (Single-Page Applications, SPAs). SPAs laden eine einzelne Seite und eine ganze Menge JavaScript. Ab der Beendigung des Ladevorgangs führt JavaScript dann die Benutzeroberfläche der "Seite" aus und aktualisiert sie.

Anstatt von Seite zu Seite zu wechseln, navigieren Benutzer von Zustand zu Zustand. Ein Zustand steht für einen Modus, in dem sich Ihre Anwendung momentan befindet. Man spricht beispielsweise von Listenansichtzustand, Datensatzansichtzustand usw.

Die SPA "weiß", welche Komponenten für jeden Zustand geladen werden müssen, und diese Komponenten "wissen", wie sie sich darstellen oder rendern müssen.

Zwei Dinge sollten Sie sich hier merken: Punkt 1: Die Navigation ist bei Aura-Komponenten ganz anders. Je nachdem, wie komplex Ihre Anwendung ist und wo sie ausgeführt wird, müssen Sie sich eventuell gar keine Gedanken über die Navigation machen. Verabschieden Sie sich von PageReference, $Action und dem Anti-Pattern handgestrickter URLs. (Der Horror!)

Wahrscheinlich müssen Sie ein paar neue Tricks lernen. Im Abschnitt "Ressourcen" finden Sie entsprechende Links.

Punkt 2: ... behandeln wir besser als eigenes Konzept.

Konzept: Seite im Vergleich zu Komponente

Wir haben bereits erklärt, wie Visualforce-Seiten und Aura-Komponenten in Salesforce gespeichert werden. Es gibt zwar einige Unterschiede bei Details, doch im Großen und Ganzen sind die beiden hier noch ziemlich identisch. Es handelt sich um einen Codeblock, und dieser Seiten- oder Komponenten-Block ist der Grundbaustein, den Sie verwenden.

Doch wie Sie mit den beiden Blocktypen bauen, unterscheidet sich deutlich (das überrascht Sie jetzt bestimmt nicht, oder?).

Hinweis

Hinweis

Für den Moment ignorieren wir Visualforce-Komponenten erst einmal. Wir widmen uns ihnen im nächsten Abschnitt.

Einfach ausgedrückt, ist eine Visualforce-Seite ein "großer" Baustein. Sie können eine Seite zwar als "Widget" zu einem Seitenlayout hinzufügen oder eine Seite mit dem Tag <apex:include> in eine andere Seite einbinden, doch das tun Sie wahrscheinlich nur mit einer Handvoll Seiten. Sie stellen keine Sammlung "kleiner" Seiten zusammen, um eine "mittelgroße" Seite zu erstellen, und setzen dann mehrere dieser Seiten zu einer "großen" Seite zusammen. Visualforce ist nicht darauf ausgelegt, und wenn Sie es trotzdem versuchen, müssen Sie mit fehlerhaftem Verhalten rechnen.

Bei Aura-Komponenten ist dies anders. Eine "große" Aura-Komponente kann aus Dutzenden oder gar Hunderten kleiner Komponenten zusammengesetzt werden, die selbst wiederum aus vielen, noch kleineren Komponenten bestehen können. Das Aura-Programmiermodell wurde dafür konzipiert, Tausende von Komponenten zu verarbeiten, die zu einer einzelnen Anwendung zusammengesetzt wurden.

Der grundlegende Designprozess bei Verwendung von Aura-Komponenten sieht vor, dass man kleine, detaillierte Komponenten hernimmt und sie zu einer Komponente "der nächsthöheren Ebene" zusammensetzt. Diesen Schritt wiederholt man dann mehrere Male nacheinander. Im Softwaredesign spricht man hier von Komposition. Hier fällt die Ähnlichkeit der Begriffe "Komponente" und "Komposition" auf (die Vorsilbe com stammt aus dem Lateinischen und bedeutet zusammen oder mit). Das ist nicht aus Versehen so.

Eine Visualforce-Seite wird mehr oder weniger eigenständig konzipiert. Das ist unter anderem ein Grund dafür, dass eine Seite mit einem eindeutigen, permanenten URL aufgerufen werden kann.

Eine Aura-Komponente sollte dagegen Teil eines großen Ganzen sein – ganz gleich, wie "groß" diese Komponente ist. Sie können nicht über einen spezifischen URL auf eine einzelne Komponente zugreifen. Zum Ausführen einer Komponente müssen Sie sie zu einer größeren Einheit hinzufügen, so wie wir dies im Modul Aura-Komponenten – Kenntnisse und Tools getan haben.

Es gäbe noch viel, viel mehr zu dieser Verwendung von Komponenten in der Softwareentwicklung zu sagen, es wurden sogar ganze Bücher darüber geschrieben. Doch das würde unseren Rahmen hier sprengen. Vorerst genügt es, wenn Sie sich Folgendes merken: Eine Komponente darf nicht wie eine Seite behandelt werden!

Konzept: Komponente im Vergleich zu Komponente

In den vorherigen Abschnitten haben wir die Visualforce-Komponenten ignoriert. Das scheint uns nicht ganz fair zu sein. Schließlich sind viele integrierte "Tags" des Visualforce-Frameworks nichts als Komponenten mit einer anderen Bezeichnung. Natürlich hat Visualforce Komponenten, und Visualforce-Seiten können Hunderte der integrierten "Tags" nutzen. Das klingt ziemlich ähnlich wie bei Aura-Komponenten. Worin besteht der Unterschied?

Einfach gesagt: Wenn wir bei Salesforce eine neue Visualforce-Komponente (oder Tag) erstellen, stehen uns mehr Funktionen zur Verfügung als wenn Sie benutzerdefinierte Visualforce-Komponenten erstellen. Viele dieser Funktionen stellen wir bei Aura-Komponenten kundenseitig wieder zur Verfügung. Benutzerdefinierte Visualforce-Komponenten sind weniger leistungsfähig und haben einen geringeren Funktionsumfang als benutzerdefinierte Aura-Komponenten.

Wichtiger Hinweis! Viele unserer Kunden erstellen sehr effizient benutzerdefinierte Visualforce-Komponenten. Benutzerdefinierte Visualforce-Komponenten sind gut! Es ist prima, sie zu verwenden! Sie sind ein Zeichen für anspruchsvolle Entwicklungsarbeit und führen meist im Lauf der Zeit zu Kostensenkungen bei der Softwareentwicklung. Wir sagen hier nicht, dass benutzerdefinierte Visualforce-Komponenten schlecht sind!

Aber Aura-Komponenten sind besser. Sie sind höher entwickelt und leistungsstärker. Im Lauf der Zeit und bei richtiger Verwendung können Sie damit leistungsfähigere, bessere Software zu vergleichbaren Kosten erstellen.

Am besten sehen wir uns ein paar der größten Unterschiede genauer an.

  • Aura-Komponenten können Ereignisse auslösen und empfangen. Dies ermöglicht die Kommunikation unter Komponenten. Sie können mit Framework- oder Container-Ereignissen arbeiten oder eigene Ereignisse definieren. Sie schreiben Ereignishandler, und das Framework kümmert sich um Details wie den Handleraufruf, wenn das entsprechende Ereignis eintritt. Dies ist wirklich gewaltig und setzt völlig neue Maßstäbe in der Anwendungsentwicklung. In Visualforce gibt es nichts Vergleichbares, es sei denn, Sie haben es selbst geschrieben. In diesem Fall kann man Ihnen dann nur noch gratulieren: Sie haben Ihr eigenes Framework geschaffen! Jetzt brauchen Sie nur noch einen ironisch gemeinten Namen, ein GitHub-Repository und einen coolen Hut.
  • Die Paketstruktur von Aura-Komponenten verfügt über separate Artefakte für separate Funktionen und "verdrahtet" diese miteinander. Die Möglichkeit, die wichtigsten Abhängigkeiten einer Komponente zu gruppieren und andere Elemente separat zu lassen, ist eine großartiges Hilfsmittel bei der Organisation. Wertanbieter usw. machen es leicht, die verschiedenen Elemente mit minimalem Brimborium zu verwenden. Auch hier gilt: Wenn man etwas Vergleichbares in Visualforce haben möchte, muss man Framework-Code schreiben.
  • Aura-Komponenten können in mehreren Kontexten verwendet werden. Da es sich um clientseitigen Code handelt, können Sie sogar Lightning Out verwenden, um Ihre "Salesforce"-Funktionen in andere Anwendungen und Kontexte zu ziehen, die überhaupt nichts mit Salesforce zu tun haben. Denken Sie da gerade an SharePoint? Das servergebundene Visualforce kann nur in Salesforce ausgeführt werden.

Wir könnten diese Liste noch ein Weilchen fortführen, doch es ist vielleicht besser, wenn wir uns weiteren Konzepten zuwenden. Hoffentlich haben Sie am Ende diese Moduls eine konkrete Vorstellung davon, warum Sie Aura-Komponenten ernsthaft in Erwägung ziehen sollten.

Konzept: Anwendungscontainer

Anwendungscontainer (kurz "Container") sind für die meisten Salesforce-Entwickler ein neues Konzept. Einfach ausgedrückt handelt es sich bei einem Container um einen Anwendungskontext oder eine Umgebung, in denen Ihr Code ausgeführt wird. Der offensichtlichste Container für Ihre Aura-Komponenten ist Lightning Experience. Da Lightning Experience und die Salesforce-Anwendung viel Code gemeinsam nutzen, auf den Sie mit demselben URL zugreifen, bezeichnen wir die Kombination aus den beiden manchmal als "one.app.container". (Der gemeinsame URL für beide endet mit one.app.)

Hinweis

Hinweis

Es gibt wichtige Unterschiede zwischen Lightning Experience und der Salesforce-Anwendung, da der Zugriff auf die Salesforce-Anwendung meist über eine native Anwendung auf einem Mobilgerät und nicht in einem Webbrowser erfolgt. Wir gehen hier nicht näher darauf ein, wollten Sie aber daran erinnern.

Sie haben vielleicht schon erraten, dass mindestens ein weiterer Container der Salesforce Classic-Container ist. Es folgt eine (nicht unbedingt vollständige) Liste verschiedener Container, in denen Ihr Code ausgeführt werden könnte.

  • Salesforce Classic
  • Visualforce
  • Salesforce-Anwendung
  • Lightning Experience
  • Lightning-Anwendungsgenerator
  • Lightning-Konsolenanwendungen
  • Communities
  • Lightning-Komponenten für Visualforce (LC4VF)
  • Lightning Out
  • Lightning für Outlook und Lightning für Gmail
  • Eigenständige my.app

Wahrscheinlich drängen sich Ihnen einige Fragen auf, wenn Sie diese Liste gelesen haben.

  1. Das sind echt viele Container. Worin besteht der Unterschied? Muss mich das überhaupt interessieren? (Die kurze Antwort lautet: Container-Services.)
  2. Moment mal. Sind diese Container nicht zum Teil dasselbe? Sind Seiten aus dem Anwendungsgenerator nicht bloß Lightning Experience? Warum ist Visualforce ein eigener Container und wie unterscheidet sich dieser von LC4VF? (Die kurze Antwort lautet: Puppen in der Puppe.)

Container-Services

Wie Sie wissen, handelt es sich bei einem Container um einen Anwendungskontext oder eine Umgebung, in denen Ihr Code ausgeführt wird. Unterschiedliche Umgebungen bieten unterschiedliche Services.

Der Container "one.app" (Lightning Experience und Salesforce-Anwendung) bietet zum Beispiel eine Reihe von Services, einschließlich der Verarbeitung von Ereignissen, um zu einem Datensatz zu wechseln, einen Datensatz zu erstellen oder zu bearbeiten, einen URL aufzurufen usw.

Andere Container bieten diese Services nicht. Eine Komponente, die von Services in einem Container abhängt, funktioniert in einem anderen Container, der diese Services nicht bietet, nicht. Wenn Sie beispielsweise das Ereignis force:createRecord zum Erstellen neuer Datensätze verwenden, funktioniert das in Lightning Experience wunderbar. Verwenden Sie diese Komponente jedoch in einer eigenständigen Anwendung oder Lightning Out, funktioniert sie nicht mehr, da kein Handler für das Ereignis zur Verfügung steht.

Wenn ein Baum im Wald umfällt, aber niemand da ist, um das zu hören - macht der Baum dann ein Geräusch? Diese Frage überlassen wir besser den Philosophen.

In unserer Lektion ist eher folgende Frage relevant: Wenn ich ein Ereignis in einem Container auslöse, der keinen entsprechenden Empfänger enthält, hat das Ereignis dann überhaupt eine Wirkung? Diese Frage können wir selbst beantworten. Nein.

Über die Grundlagen hinaus

Wie lässt sich dieses Problem umgehen? Schreiben Sie einen eigenen Container-Service zum Erstellen von Datensätzen und einen Ereignishandler, der das Ereignis force:createRecord empfängt und an Ihren benutzerdefinierten Service sendet.

Falls dies nach Arbeit riecht, liegt dies wohl daran, dass das wirklich Arbeit macht. Die Bereitstellung robuster Container-Services ist hart. Ganze Entwicklungsteams sind nur dafür abgestellt. Arbeiten Sie sich bis zu diesem Thema für Fortgeschrittene vor und prüfen Sie in der Zwischenzeit, ob AppExchange Services bietet, die Sie für die Verwendung außerhalb von Lightning Experience und der Salesforce-Anwendung brauchen.

Es würde den Rahmen sprengen, hier sämtliche Services und ihre Container-Zugehörigkeit aufzulisten. Schlagen Sie Funktionen, die Sie einsetzen möchten, in der Dokumentation nach und achten Sie auf Hinweise wie den folgenden.

This event is handled by the one.app container. (Dieses Ereignis wird vom Container 'one.app' verarbeitet.) It's supported in Lightning Experience and the Salesforce app only. (Es wird nur in Lightning Experience und in der Salesforce-Anwendung unterstützt.)

Container-Kapselung (auch Prinzip "Puppe in der Puppe" genannt)

Ein Container hat Abgrenzungen. Wände. Barrieren. Der Container sorgt dafür, dass sein Inhalt drinnen bleibt und Dinge von außen draußen bleiben.

Dies gilt auch für Anwendungscontainer. Bei Webanwendungen und Frameworks basieren die Abgrenzungen häufig auf einem HTML IFrame, der vom Browser umgesetzt wird. Code im IFrame kann nicht direkt auf Elemente außerhalb des IFrame zugreifen.

Es gibt noch andere Abgrenzungen. Der Container selbst kann beispielsweise eine Abgrenzung erzwingen, indem er innerhalb der Abgrenzung ausgelöste Ereignisse erfasst.

Jetzt kommt der Teil, der richtig Spaß macht. Sie können kleinere Container in größeren Containern platzieren und damit mehrere "Ebenen" in der Kapselungshierarchie schaffen. Die ineinander schachtelbaren russischen Matrjoschka-Puppen sind eine hervorragende Metapher für die Anwendungscontainer Ihrer Aura-Komponenten. Container, die Container enthalten, die Container enthalten ...

Mit LC4VF können Sie Aura-Komponenten (4) in einer Visualforce-Seite (3) ausführen. Dann können Sie diese Visualforce-Seite zu Lightning Experience hinzufügen. Das ergibt schon drei Container. Sie können auch LAB verwenden, um die Visualforce-Seite zu einer Lightning-Seite (2) hinzuzufügen, und können diese Lightning-Seite dann zu Lightning Experience (1) hinzufügen. Das ergibt dann vier Container. Und es ist keineswegs schwierig, auf fünf oder gar sechs Kapselungsebenen zu kommen.

Jetzt kommt der Teil, der richtig wichtig ist. Ihr Aura-Komponentencode kann nur auf die Services des Containers zugreifen, in dem er ausgeführt wird. Dies gilt auch dann, wenn sich dieser Container innerhalb eines anderen Containers befindet.

Was bedeutet dies für die Aura-Komponente innerhalb einer Visualforce-Seite? Die Komponente kann keine funktionierenden Lightning Experience-Ereignisse auslösen, da der Visualforce-Container die Ereignisse nicht versteht und auch nicht zum nächsthöheren Container weiterleitet, selbst wenn Sie diese Visualforce-Seite zu Lightning Experience hinzufügen. Die iframe-Abgrenzung zwischen Visualforce und Lightning Experience blockiert solche Ereignisse.

Kurz und bündig: Ihre Komponente kann nur die Services des Containers nutzen, in dem sie ausgeführt wird. Wenn Sie eine Komponente für mehrere Kontexte erstellen, benötigen Sie mehrere Codepfade für die verschiedenen Gruppen von Services. Unter Lightning Components in Visualforce with Lightning Out finden Sie ein Beispiel für dieses Verfahren.