‫Kursleiter: Bis zu
‫diesem Punkt haben wir nur unseren Code geschrieben,
‫ohne viel über unsere Anwendungsarchitektur nachzudenken.
‫Bisher war es nicht wirklich wichtig, aber
‫jetzt, da unsere App wirklich zu wachsen beginnt, müssen wir
‫uns Gedanken über
‫die Art und Weise machen, wie wir entwerfen oder die Codearchitektur.
‫Und dieser Vortrag wird nur eine kurze Einführung
‫in die Backend-Architektur sein.
‫Beginnend mit der MVC-Architektur.
‫In diesem Projekt werden
‫wir also eine weit verbreitete und bekannte
‫Architektur verwenden, die als Model, View, Controller
‫oder kurz MVC bezeichnet wird.
‫Und es
‫gibt verschiedene Möglichkeiten, die MVC-Architektur zu implementieren,
‫einige komplexer als andere, aber
‫wir werden sie
‫hier auf sehr einfache Weise implementieren.
‫Ich wollte Sie nur wissen
‫lassen, dass Sie, wenn Sie nach MVC
‫googeln, feststellen, dass es auf verschiedene Weise implementiert wird.
‫Okay, in dieser Architektur befasst sich
‫die Modellschicht mit
‫allem, was Anwendungsdaten und die
‫Geschäftslogik betrifft.
‫Und wir werden auf der nächsten Folie lernen,
‫was Geschäftslogik bedeutet.
‫Als nächstes haben wir die Controller-Schicht und
‫die Funktion der Controller besteht
‫darin, die Anforderung der Anwendung zu verarbeiten,
‫mit Modellen zu
‫interagieren und Antworten an den Client zurückzusenden.
‫Und all das nennt man Anwendungslogik.
‫Schließlich ist die Ansichtsebene erforderlich, wenn
‫wir eine grafische Oberfläche in unserer App haben.
‫Oder mit anderen Worten, wenn wir
‫eine serverseitig gerenderte Website erstellen, wie
‫wir zuvor besprochen haben.
‫In diesem Fall besteht die Ansichtsebene im Wesentlichen
‫aus den Vorlagen, die zum Generieren
‫der Ansicht verwendet werden, also der Website, die wir an den Client zurücksenden.
‫Und das ist die Präsentationslogik.
‫Im Moment erstellen wir jedoch nur eine
‫API, sodass wir uns noch nicht wirklich um Ansichten kümmern.
‫Das ist für etwas später im Kurs.
‫Die Verwendung eines Musters oder einer solchen Architektur ermöglicht
‫es uns, eine modularere Anwendung zu schreiben,
‫die bei Bedarf viel einfacher zu
‫warten ist.
‫Und wir könnten noch
‫weiter gehen und hier weitere Abstraktionsebenen hinzufügen.
‫Aber in dieser Art von kleineren
‫Anwendungen ist die MVC-Architektur mehr als genug für unsere Bedürfnisse.
‫Das alles mag jetzt
‫etwas abstrakt klingen, also werfen wir einen Blick auf MVC
‫im Kontext unserer App und den Anfrage-Antwort-Zyklus.
‫Alles beginnt also wie immer mit einer Anfrage.
‫Diese Anfrage wird einen unserer Router treffen, denn denken
‫Sie daran, dass wir mehrere Router haben.
‫Grundsätzlich eine für
‫jede Ressource, wie Touren, Benutzer usw.
‫Das Ziel des Routers besteht nun darin, die Anfrage
‫an die richtige Handler-Funktion
‫zu delegieren, die sich in einem der Controller befindet.
‫Und wieder wird es für
‫jede unserer Ressourcen einen
‫Controller geben, um diese verschiedenen Teile der App sauber zu trennen.
‫Dann muss der Controller je nach
‫eingehender Anfrage möglicherweise mit einem der
‫Modelle interagieren, um beispielsweise
‫ein bestimmtes
‫Dokument aus der Datenbank abzurufen
‫oder ein neues zu erstellen.
‫Auch hier gibt es für jede Ressource eine Modelldatei.
‫Nach dem Abrufen der Daten aus
‫dem Modell kann der Controller dann möglicherweise bereit sein,
‫eine Antwort an den Client zurückzusenden, die beispielsweise diese Daten enthält.
‫Falls wir nun tatsächlich eine Website rendern möchten,
‫ist ein weiterer Schritt erforderlich.
‫In diesem Fall wählt der Controller nach dem
‫Abrufen der Daten aus
‫dem Modell eine der Ansichtsvorlagen aus und fügt die Daten ein.
‫Diese gerenderte Website wird dann
‫als Antwort zurückgesendet.
‫In der Ansichtsebene einer Express-App
‫gibt es normalerweise eine Ansichtsvorlage für jede Seite.
‫Wie eine Tourübersichtsseite,
‫eine Tourdetailseite oder eine Anmeldeseite.
‫Am Beispiel unserer neuesten App natürlich.
‫Das ist also ein breiter Überblick über die Architektur, die
‫wir in diesem Projekt implementieren werden.
‫Lassen Sie mich nun zum
‫Abschluss noch etwas mehr auf Modell und Controller eingehen.
‫Eines der großen Ziele von MVC besteht
‫also darin, die Geschäftslogik
‫von der Anwendungslogik zu trennen.
‫Sie werden ständig von dieser Art von Logik
‫hören, wenn Sie Stack
‫Overflow oder eine ähnliche Site durchsuchen.
‫Aber was sind diese Arten von Logik eigentlich?
‫Nun, der Unterschied ist ein bisschen eigenwillig, aber
‫so sehe ich ihn: Anwendungslogik ist
‫also der gesamte Code, der sich nur um
‫die Implementierung der
‫Anwendung kümmert und nicht um
‫das zugrunde liegende Geschäftsproblem, das
‫wir tatsächlich mit der Anwendung lösen möchten .
‫Wie zum Beispiel Führungen zeigen
‫und verkaufen, Lagerbestände in einem Supermarkt
‫verwalten oder zum Beispiel eine Bibliothek organisieren.
‫Auch hier ist die Anwendungslogik
‫die Logik, die dafür sorgt, dass die App tatsächlich funktioniert.
‫Ein großer Teil der Anwendungslogik in Express besteht
‫beispielsweise darin, Anfragen und Antworten zu verwalten.
‫In gewisser Weise können wir also
‫auch sagen, dass es bei der Anwendungslogik mehr um technische Dinge geht.
‫Wenn wir Ansichten in unserer App
‫haben, dient die
‫Anwendungslogik außerdem als Brücke zwischen Modell-
‫und Ansichtsschichten, sodass wir
‫niemals Geschäftslogik mit Präsentationslogik vermischen.
‫Gut?
‫Was die Geschäftslogik betrifft,
‫ist es der gesamte Code, der das Geschäftsproblem
‫löst, das wir lösen wollten.
‫Sagen wir noch einmal, unser Ziel ist es, Kunden Touren zu zeigen und
‫diese dann zu verkaufen.
‫Und der Code, der in direktem Zusammenhang mit den
‫Geschäftsregeln, der Funktionsweise des
‫Geschäfts und den Geschäftsanforderungen steht, ist die Geschäftslogik.
‫Wenn das jetzt noch etwas zu philosophisch klingt,
‫einige Beispiele im Zusammenhang mit unserer neuesten App
‫sind das Anlegen neuer Touren in der Datenbank der
‫App, die Überprüfung des Passworts eines Benutzers beim Einloggen, das Validieren
‫von Benutzereingaben oder das Sicherstellen,
‫dass nur Benutzer wer eine bestimmte Tour gekauft hat,
‫kann sie bewerten.
‫All diese Dinge beziehen sich also auf das Geschäft
‫selbst und sind daher Teil der Geschäftslogik.
‫Nun müssen wir
‫bedenken, dass Anwendungslogik und Geschäftslogik
‫fast nicht vollständig voneinander getrennt werden können
‫und sich daher manchmal überschneiden.
‫Aber wir sollten unser
‫Bestes tun, um die Anwendungslogik in unseren
‫Controllern und die Geschäftslogik in unseren Modellen zu behalten.
‫Und es gibt sogar diese
‫Philosophie der fetten Modelle, dünner Controller,
‫die besagt, dass wir
‫so viel Logik wie möglich in die Modelle verlagern
‫sollten, um die Controller so einfach und schlank wie möglich zu halten.
‫Ein Fat-Modell wird also so viel Geschäftslogik haben, wie
‫wir können, und ein Thin-Controller
‫wird so wenig Logik wie möglich haben, sodass der Controller
‫wirklich hauptsächlich für
‫die Verwaltung der Anforderungen und Antworten der Anwendung
‫zuständig ist.
‫Okay?
‫Behalten Sie all dies jetzt im
‫Hinterkopf, während wir mit der Entwicklung unserer Anwendungen fortfahren.