Das Programmierprinzip \"Separation of Concerns\"

Lernziele

Nachdem Sie diese Lektion abgeschlossen haben, sind Sie in der Lage, die folgenden Aufgaben auszuführen:

• Erläutern der unternehmerischen Vorteile des Programmierprinzips "Separation of Concerns" (SOC)
  
• Verwenden von SOC, um Ihre Lösung an veränderte Benutzeranforderungen oder Plattformtechnologien anzupassen
  
• Anwenden von SOC auf die Entwicklung in Salesforce
  
• Feststellen, wann SOC angewendet werden sollte
  

Einführung

Software wird oftmals mit Lebewesen verglichen, die sich Lauf der Zeit weiterentwickeln. Von der einzelligen Amöbe des Programms "Hello World" zur Komplexität von Software auf Unternehmensniveau – die Vielzahl und Vielfalt der Lebewesen lässt sich auch bei Software feststellen. Komplexe Organismen entwickeln Systeme für spezielle Zwecke. Skelett, Muskulatur und Organe arbeiten als Einheit zusammen, haben aber auch Schnittstellen zu anderen Systemen, wovon der Gesamtorganismus profitiert.

Dasselbe gilt für komplexe Unternehmensanwendungen. Die Trennung der verschiedenen Belange und Aufgaben in verschiedene Systeme oder Schichten erleichtert die Navigation im Code und seine Pflege. Wenn Änderungen vorgenommen werden, werden die Auswirkungen und Regressionen in anderen Bereichen minimiert und ein stabileres und anpassungsfähigeres Programm entsteht.

Mit Trail Together einem Dozenten folgen

Möchten Sie bei diesem Schritt einem Experten folgen? Schauen Sie sich dieses Video an, das Teil der Reihe "Trail Together" ist.

Separation of Concerns (SOC)

Codey, der Bär, sagt oft: "Der beste Code wird abseits der Tastatur geschrieben". Anders ausgedrückt heißt dies, dass guter Code häufig durch sorgfältige Planung und Weitsicht entsteht. Erinnern Sie sich an diese Empfehlung, wenn Sie planen, wo Sie Ihren Code ablegen wollen. Codieren sollte einfach sein, wenn man weiß, wohin man will!

Komplexer Code gerät außer Kontrolle, wenn man ihn nicht richtig unterteilt. Wenn Code stark vermischt ist, wird er fehleranfällig, schwer zu warten und schwer zu durchschauen. Haben Sie schon einmal versucht, den Spaghetticode von jemandem zu debuggen? Und die Probleme werden noch schlimmer, wenn Sie neue Entwickler ins Team holen. Das Erstellen von Modulen oder Bibliotheken zur gemeinsamen Nutzung von Berechnungen und Prozessen in verschiedenen Anwendungsteilen ist oft der erste Schritt zur Wiederverwendung von Code, was natürlich eine gute Sache ist!

Ist SOC dann nur ein schicker Ausdruck für "Code-Wiederverwendung"?

Ja... und Nein. SOC erfordert eine gewisse Vorausplanung hinsichtlich des internen Gerüsts Ihrer Anwendung, einschließlich der Benennungskonventionen für Klassen und Programmierrichtlinien. Sie möchten, dass diese Planung Bestand hat und für andere selbsterklärend ist. Guter Code sollte eine Geschichte erzählen. Der übliche Ansatz zur Wiederverwendung von Code ist das Verschieben von Codefragmenten, sobald zwei oder mehr Bereiche dies erfordern. Der Code wird oft nur in MyUtil-Klassen oder einem anderen generischen Ablagebereich platziert. Das ist in Ordnung und empfiehlt sich zum Kopieren und Einfügen!

Was sind die Vorteile von SOC?

Im Prinzip bestehen Anwendungen aus drei Dingen: Speicher, Logik und einer Möglichkeit der Interaktion mit der Anwendung, sei es durch Menschen, Waldbewohner oder andere Anwendungen. Wenn Sie diese Dinge trennen, können Sie beginnen, Schichten innerhalb Ihrer Anwendung zu definieren – jede mit ihren eigenen Aufgaben und Verantwortlichkeiten gegenüber anderen Schichten und der Anwendung als Ganzes. Die sorgfältige Beachtung und Verwaltung dieser Schichten ist wichtig für die Umsetzung von SOC.

• Weiterentwicklung. Wenn sich im Lauf der Zeit Technologie, Verständnis und Anforderungen (sowohl funktional als auch technisch) weiterentwickeln, muss eine Schicht möglicherweise erweitert, überarbeitet oder sogar ganz weg gelassen werden. Ein Paradebeispiel ist hier die Benutzeroberflächen-Technologie der letzten zehn Jahre. Wie viele JavaScript-Frameworks können Sie aufzählen, bevor Sie ohnmächtig werden?
  
• Umgang mit Auswirkungen: Das Ändern oder Entfernen einer oder mehrerer Schichten sollte keine übermäßigen Auswirkungen auf andere Schichten haben, es sei denn, dies ist aufgrund von Anforderungen beabsichtigt.
  
• Rollen und Verantwortung. Jede Schicht hat ihre eigene Verantwortung und darf diese nicht über- oder unterschreiten. Wenn Sie beispielsweise eine Client-Technologie oder -Bibliothek zugunsten einer anderen aufgeben, bedeutet dies nicht, dass Sie die Geschäftslogik verlieren, da diese in der Verantwortung einer anderen Schicht liegt. Wenn die Grenzen der Verantwortung verschwimmen, werden Zweck und Nutzen der SOC ausgehöhlt, was nicht gut ist.
  

In der Salesforce-Plattform werden zwei unterschiedliche Entwicklungsansätze verfolgt: deklarative (Point-and-Click) und traditionelle Programmierung. Sie können jede dieser beiden Methode allein oder in Kombination verwenden. Die beiden Ansätze passen, wie nachfolgend beschrieben, zu den SOC-Standardschichten.

Darstellung

• Deklarativ: Layouts, Datensatzseiten, Flow, Datensatztypen, Formeln, Berichte, Dashboards
  
• Codierung: Apex-Steuerfelder, Visualforce, Lightning Components
  

Geschäftslogik

• Deklarativ: Formeln, Flow, Validierungsregeln, Freigaberegeln, Genehmigungsprozesse
  
• Codierung: Apex-Services, benutzerdefinierte Apex-Aktionen, asynchrones Apex
  

Datenzugriff

• Deklarativ: Data Loader, Salesforce Connect
  
• Codierung: SOQL, SOSL, Salesforce APIs
  

Datenbank

• Deklarativ: Benutzerdefinierte Objekte, Felder, Beziehungen, Rollups
  
• Codierung: Apex-Auslöser
  

Wann SOC bei Salesforce nicht notwendig ist

Ein wesentlicher Vorteil von Salesforce ist sein deklaratives Entwicklungsmodell, mit dem Sie Objekte, Felder, Layouts, Validierungsregeln, Workflows, Formelfelder und vieles mehr erstellen können, ohne eine einzige Zeile Code schreiben zu müssen. Die deklarative Entwicklung ist schneller und einfacher und implementiert bereits ein gewisses Maß an SOC. Wenn Ihre Anwendung stark datenzentriert ist und Sie einen großen Teil Ihrer Anwendung deklarativ bereitstellen können, sollten Sie also das Rad nicht neu erfinden, sondern es einfach verwenden!

Obwohl es kein Code ist, ist das, was Sie mit deklarativer Entwicklung erreichen können, immer noch eine Architekturschicht in Ihrer Anwendung, über die wir später noch sprechen werden.

Wann SOC bei Salesforce umgesetzt werden sollte

Wenn Ihre Anwendung prozessorientiert ist oder Sie gedrängt werden, komplexere Berechnungen, Validierungen oder umfangreichere UI-Erfahrungen zu implementieren, werden Sie den Schritt in das Land des Apex-Codes wagen. Salesforce bietet viele Orte, an denen Sie Apex-Code platzieren können, wie z. B. Auslöser, Klassen mit @AuraEnabled-Methoden, APIs, Batch-Apex und E-Mail-Handler.

Sie können viel in die Entwicklung und das Testen von Code investieren, aber es ist die Geschäftslogik, deren Schutz Ihnen am meisten am Herzen liegt. Wir befassen uns zu einem späteren Zeitpunkt mit Richtlinien für das Schreiben von Geschäftslogik, möchten uns vorerst aber die folgenden Beispiele für die Anwendung von SOC in Salesforce ansehen.

• Ersetzen oder Hinzufügen von Benutzeroberflächenteilen in Ihrer Anwendung: Überlegen Sie, wie viel Code Sie neu schreiben oder portieren müssen, der nichts mit der Benutzeroberfläche zu tun hat, sondern die Einfüge-, Aktualisierungs-, Validierungs- und Berechnungsfunktionen Ihrer Anwendung beeinflusst.
  
• Bereitstellen einer öffentlich ausgerichteten API für Ihre Logik: Stellen Sie fest, welche Teile Ihrer bestehenden Codebasis Sie aufrufen würden, um die API zu implementieren. Ist die Verwendung Ihrer @AuraEnabled-Methoden eine gute Grundlage für eine API? (Die Antwort lautet "Nein".)
  
• Skalieren Ihrer Anwendungslogik über Batch-Apex: Wenn Sie weiterhin eine interaktives Erfahrung (für kleinere Volumina) über Ihre bestehende Benutzeroberfläche anbieten müssen, wie würden Sie die Logik gemeinsam mit den beiden Versionen nutzen, um sicherzustellen, dass der Benutzer unabhängig von der Größe konsistente Ergebnisse erhält?
  
• Verwenden komplexer Logik in Ihren Visualforce-Steuerfeldern oder @AuraEnabled-Methoden: Geht es in Teilen Ihres Codes um mehr als nur um den Umgang mit Informationen vom und an den Benutzer? Mit Visualforce und Lightning Components können Sie Ihren Code über das MVC-Paradigma (Model-View-Controller), einer Form von SOC für die Client-Entwicklung, unterteilen. Die Verwendung von Steuerfeldern für Ihren gesamten Code garantiert jedoch nicht, dass Sie SOC in Bezug auf Ihre Geschäftslogik einhalten.
  
• Einfachere Orientierung für neue Entwickler innerhalb der Codebasis: Wie viel Zeit braucht ein Entwickler, um festzustellen, wo er neuen Code einfügen und vorhandenes Verhalten finden kann?
  

Je nachdem, wo Sie Ihren Code geschrieben haben, sind Sie vielleicht schon gut gerüstet, um einige der oben genannten Szenarien in Angriff zu nehmen. Falls dies nicht der Fall ist oder Sie nur neugierig sind, erhalten Sie in den kommenden Einheiten etwas mehr Details, um weitere Überlegungen anstellen zu können. Die folgende Tabelle kann Ihnen ebenfalls bei der Entscheidung helfen, ob Sie diese Muster verwenden möchten. Grundlage dafür sind Größe und Umfang der von Ihnen erstellten Lösung.

Ressourcen

• Separation of Concerns (Wikipedia)
• "Enterprise Architecture Patterns" von Martin Fowler