Oberes Architektur-Frontend. Yandex-Vortrag

Published on October 07, 2018

Oberes Architektur-Frontend. Yandex-Vortrag

    Die Wahl der richtigen Architektur ist ein Schlüsselelement beim Aufbau eines Service-Frontends. Die Entwicklerin Anna Karpelevich erzählte den Studenten der Interface Development School, was Architektur ist, welche Funktionen sie ausführt und welche Probleme sie löst. In der Vorlesung erfahren Sie mehr über die beliebtesten Architekturansätze im Frontend: Model-View- * und Flux.


    - Guten Abend. Ich heiße Anya Karpelevich. Heute werden wir über die Architektur des Frontends der oberen Ebene sprechen.

    Ich arbeite in Direct. Wir machen Schnittstellen für Werbetreibende. Sie schalten Anzeigen und passen sie an. Dies ist ein sehr komplexes, interessantes System, es gibt viele miteinander verbundene Komponenten, sie wachsen ineinander, sie haben gemeinsame und eigene Funktionalitäten. "Hosen werden zu eleganten Shorts." All dies muss sehr sorgfältig kontrolliert werden. Und die Architektur in unseren Anwendungen ist sehr komplex. Dies ist einer der Gründe, warum ich diesen Vortrag heute lese. Ich liebe dieses Thema wirklich.

    Was ist Architektur? Tatsache ist, dass die Antwort auf diese Frage wahrscheinlich nicht ist. Oder gibt es, aber jeder hat seine eigene. Dies ist ein sehr kontroverses Thema. Es verursacht viele Kontroversen, viele Holivare. Und vieles, was ich heute erzähle, ist meine Meinung. Teilweise wird es von meiner Arbeitsgruppe unterstützt, teils - nicht sehr viel. Und jeder, der die Architektur seiner Anwendung schreibt, entscheidet selbst, wie und was zu tun ist.

    Aus diesem Grund ist Architektur einer der wahrscheinlich kreativsten Orte in der Arbeit eines Programmierers. Deshalb beginnt unsere heutige Präsentation auch mit Kreativität.



    Schauen wir uns das linke Bild an. Ich bin sehr glücklich, wenn jemand das abgebildete Gebäude erkennt. Dies ist die Kirche von Saint-Sulpice in Paris. Achte auf die Türmchen, um dieser Kirche willen wurde sie hier aufgestellt. Ich hoffe, es ist klar, dass sie anders sind. Ziemlich anders, und es gibt einen interessanten Grund. Zwischen ihnen 130 Jahre Unterschied. Dann wurde der linke Turm während des Deutsch-Französischen Krieges abgerissen und wieder aufgebaut.

    Warum ist sie hier? Schau dir dieses Bild an. Die Türme haben die gleiche Architektur und die gesamte Umgebung, diese Vignetten, Schmuckstücke und gewölbten Strukturen sind unterschiedlich. Warum so? Denn der Zweck dieser Türme ist der gleiche. Keiner von ihnen war zum Beispiel ein Glockenturm. Das sind nur Türme. Etwas wurde in ihnen gespeichert und alles andere ist anders. Warum Weil die Architektur dieser Türme gleich ist. Beide haben ein Gewölbe, nur ein Fenster und es ist spitz. Die Höhe der Fenster ist ungefähr gleich. Die Idee ist, dass Architektur sowohl Gebäude als auch Anwendungen eine unterstützende Struktur ist. Dies ist keine Vignette, kein Triller, keine Realisierung. Das ist was steht. Und diese Basis hängt in der Regel von der Umgebung ab, vom Boden, wenn es sich um ein Gebäude handelt, von dem Ziel, das sich der Architekt setzt, aber fast nie von Designerfreuden abhängt.

    Das Gebäudebeispiel für das Architekturthema ist ziemlich offensichtlich. Aber das richtige Bild ist interessanter. "Architektur ist taub." „Architektur ist gefrorene Musik“, sagte Johann Wolfgang Goethe im 18. Jahrhundert. Goethe wusste höchstwahrscheinlich nichts über die Architektur der Gebäude, er war ein Dichter. Und er garantierte, dass nichts über die Anwendungsarchitektur bekannt war. Aber er brachte eine sehr wertvolle und interessante Idee zum Ausdruck.

    Musik existiert in der Dynamik. Das ist nicht statisch. Dies ist ein Prozess. Und genauso ist eine Anwendung ein Prozess. Er hat einen Moment des Startens, er hat einen Moment der Entwicklung, wenn wir etwas mit ihm machen, arbeiten wir. Und er hat endlich einen Moment der Vollendung. Die Architektur der Anwendung ist zu einem bestimmten Zeitpunkt ihr Slice. In jedem Moment muss unsere Anwendung als musikalisches Thema klar, klar, verständlich, vorhersehbar usw. sein. Andernfalls wird alles auseinanderfallen.

    Am Ende werden wir mit einer kreativen Einführung enden.

    Was ist Architektur und warum wird sie benötigt?



    Erstens haben wir die Organisation einer großen Anzahl von Codes, mit denen wir uns in Yandex.Direct befinden, und nicht nur in Yandex.Direct, die uns ständig begegnen. Code so viel, dass es verloren gehen kann. Wir wollen uns nicht im Code verlieren.

    Zweitens die Verdoppelung der Funktionalität. Dies ist auch ein ewiges Problem, dem Sie immer begegnen werden, und heute wird dieses Thema der Vervielfältigung durch die rote Linie durch die gesamte Vorlesung gehen. Möglicherweise benötigen Sie die gleiche Funktionalität an mehreren Stellen der Benutzeroberfläche. Wenn es an mehreren Stellen benötigt wird, muss es physisch derselbe Code sein, der an mehreren Stellen verwendet wird, nicht Kopien. Warum Wir werden weiter darüber reden. Die Architektur sollte uns jedoch dabei helfen, das Kopieren und Einfügen zu vermeiden.

    Der dritte ist Unterstützung. Es liegt auf der Hand, dass wenn wir eine Anwendung haben, diese irgendwie unterstützt werden muss und es wünschenswert ist, dass nicht alle Ressourcen des Teams dafür aufgewendet werden.

    Ändern Sie die Zusammensetzung des Teams. Das gleiche, was wir im wirklichen Leben öfter treffen, als wir möchten. Jemand kommt, jemand geht, und wenn eine Person ein halbes Jahr damit verbringt, den Code einzugeben, ist das schlecht. Wenn das Wissen über den Code nur in einem Kopf gespeichert ist und dieses Wissen im Falle eines Austritts ein halbes Jahr lang übertragen wird, ist es noch schlimmer. Im Allgemeinen hilft uns die Architektur auch dabei, all dies verständlicher zu machen und den Wissensaustausch aufrechtzuerhalten.

    Funktionalität hinzufügen und erweitern. Zu offensichtlich genug. Der Manager kommt zu uns gerannt und sagt, dies sei dringend nötig. Und wenn Sie dies dringend tun müssen, müssen Sie viel Zeit und Mühe aufwenden, dann ist dies eine schlechte architektonische Entscheidung. Und wir brauchen gut.

    Und zum Schluss noch Fehler. Je klarer und vorhersehbarer unsere Architektur ist, desto einfacher ist es, Fehler zu finden, desto weniger Fehler.

    Wie kannst du das alles nennen? All dies kann man nennen - die Probleme eines komplexen Systems. Eine Anwendung ist ein komplexes System, die Architektur hilft uns, ein Problem zu lösen.



    Kurz gesagt, so etwas. Hier ist ein Bild von Nudeln zu meiner Rechten, und dies passiert, wenn Architektur nicht verfolgt wird, wenn sie nicht gebaut, durchdacht und nicht entworfen wird. Und das zweite Bild ist, was passiert, wenn Sie irgendwie über die Architektur nachdenken. Dies ist nicht Saint-Sulpice, aber zumindest der Kindergestalter, er steht fest und fällt nicht auseinander. Im Konstruktor werden wir heute auch viel spielen.



    Formal über alles. Architektur ist eine Möglichkeit, Probleme eines komplexen Systems durch Abstraktion der Implementierung von einer Schnittstelle und Autoritätsbegrenzung zwischen Codeblöcken zu lösen. Im Folgenden werden wir diesen langen Satz detailliert analysieren.

    Was zeichnet die Anwendungsarchitektur als Wissensfeld aus? Sie hat einen bestimmten Bereich, mit dem wir arbeiten. Das heißt, es ist nicht etwas Abstraktes, es ist eine sehr spezifische Sache. Hier ist die Aufgabe, wir wählen die Architektur dafür aus, aber nicht, damit ein interessanter architektonischer Ansatz versucht werden sollte. Also nein. Sie können etwas Kleines ausprobieren, aber für ein ernstes Projekt wird die Architektur ausgewählt, manchmal wird sie für ein bestimmtes Projekt zusammengestellt.

    Die Geschichte der Frage, als im Allgemeinen diese Idee entstand, dass Architektur nötig ist. Edsger Dijkstra, ein bemerkenswerter Programmierer, drückte 1968 diesen sehr ungewöhnlichen Gedanken aus. Er ist eher als Autor des Dijkstra-Algorithmus bekannt und sucht nach dem kürzesten Pfad in der Grafik. Aber er hat für seine Zeit tatsächlich viele bahnbrechende Ideen. Und einer davon ist ein Artikel, ich werde Ihnen später einen Hinweis auf die Materialien geben, Sie können lesen, es gibt nur zwei Seiten, einen kurzen Aufsatz. Es klingt wie "Operator GOTO wird als schädlich betrachtet", übersetzt als "Operator GOTO - ein bedingungsloser Übertragungsoperator - Übel." Es war der erste Gedanke, der offiziell gesagt wird, dass wir Architektur schreiben müssen und nicht Nudeln.

    In den 70er Jahren wurde diese Idee bereits von Dijkstra in Zusammenarbeit mit Parnassus und für sich allein entwickelt. Das erste detaillierte Buch zur Anwendungsarchitektur insgesamt wurde 1996 von Mary Shaw und David Garland geschrieben. Danach wurden solche detaillierten Bücher über die Softwarearchitektur tatsächlich nicht genau aufgrund des Anwendungsbereichs geschrieben, da jedes Wissensgebiet seine eigenen architektonischen Ansätze hat, irgendwo, irgendwo anders, irgendetwas im Allgemeinen , an keiner Stelle anwendbar. Und da Architektur ein kreativer Prozess ist, werden Sie keine spezifischen Bücher über das Schreiben von Architektur finden. Vielleicht gab es nach 1996 nichts besonders detailliertes zu diesem Thema.

    Was sind jetzt die Anforderungen an die Projektarchitektur? Erstens und vor allem, was von ihm verlangt wird, ist in der Tat Erweiterbarkeit, denn wenn Ihr Projekt nicht expandiert, ist es tot.

    Code wiederverwenden. Hier geht es um das Kopieren und Einfügen. Wenn Sie über zwei Blöcke verfügen, die an zwei verschiedenen Stellen verwendet werden, benötigen Sie dieselbe Funktionalität. Dann müssen Sie denselben Code wiederverwenden. Die Architektur sollte so beschaffen sein, dass jeder Code übernommen und wiederverwendet werden kann, sobald er benötigt wird. .

    Die Gewaltenteilung zwischen Codemodulen. Wir werden heute auch ausführlicher darüber sprechen, warum dies notwendig ist. Die Idee ist folgende: Jedes Modul, jeder Block, jeder Code muss eine bestimmte Aktion ausführen und genau eine Funktion ausführen. Und diese Funktion sollte in den Kopf dieser Methode (Klasse, was auch immer es sich befindet) Modul eingefügt werden. Ein Modul - eine Funktion.

    Und schließlich die Qualität der Anwendungen. Es gibt viele Dinge, die ich gerne machen würde - Zuverlässigkeit und Abwärtskompatibilität. In Wirklichkeit wieder von der Aufgabe ausgewählt. Irgendwo ist Abwärtskompatibilität erforderlich, damit sich auf gar keinen Fall etwas entfernt. Irgendwo brauchen Sie Zuverlässigkeit, damit Gott, Gott, es verbieten, Kennwörter, PIN-Codes von Karten oder CVV nirgendwo verschwinden. Irgendwo muss es problemlos sein, wenn es sich um einen Satelliten oder etwas anderes handelt. Wählen Sie im Allgemeinen ein paar aus. Je mehr Sie unterstützen möchten, desto komplexer werden Sie am wahrscheinlichsten in der Architektur sein.

    Weiter werden wir mit Ihnen über einige Definitionen sprechen, wie z. Warum ist das wichtig? Weil die Terminologie in der Architektur sehr wichtig ist und wir mit Ihnen dieselbe Sprache sprechen müssen. Die Definitionen stammen größtenteils aus dem Programmierparadigma OOP. Tatsächlich sind sie jedoch in andere Paradigmen geraten, wobei die Begriffe "Klasse, Objekt, Schnittstelle" nicht nur im Rahmen der PLO funktionieren. Diese Definitionen und dieses Verständnis stammen jedoch genau aus der Welt der PLO.



    Das einfachste ist Klasse. Was ist eine Klasse? Dies ist ein Muster, dies ist ein Beispiel. Beispiel: Snake-Klasse - Klasse Snake. In ihr haben wir drei private Felder identifiziert, d. H. Ein Feld, auf das andere Personen als die Methoden der Klasse selbst nicht zugreifen können - die Anzahl der Köpfe, die Anzahl der Schwänze und die Länge der Papageien. Wir haben einen Konstruktor definiert, in den wir diese Köpfe, Schwänze und Längen in Papageien legen. Ich habe eine Schlangenklasse. Es ist einfach



    Wir gehen weiter. Objekt Und das Objekt ist eine Instanz einer bestimmten Struktur. Und neben klassischen OOP ist gemeint, dass das Objekt ein Objekt einer Klasse ist. In der modernen Welt von JavaScript, die nicht immer die OOP-Sprache war, und selbst jetzt ist es nicht immer und nicht überall OOP, wissen wir, dass es abstrakte Objekte geben kann. Das heißt, wir können ein Objekt erstellen, ein Literal, das kein Objekt einer Klasse ist. Hier ein Beispiel, wie wir ein Objekt der Snake-Klasse erstellen. Hier haben wir eine zweiseitige Schlange mit einer Länge von 38 Papageien, eine Boa.



    Modul Ein Modul ist eine semantische Einheit. Es ist nicht immer eine Klasse. Dies kann ein Satz von Klassen sein, ein Satz von Objekten, ein Satz von Methoden, die nicht zu Klassen zusammengefasst sind. Normalerweise können wir davon ausgehen, dass das Modul das ist, was Sie in eine Datei geschrieben haben. Im Prinzip ist das Modul jedoch der Ordner, in dem sie sich befinden, z. B. die Datei und die Tests für dieses Modul sind auch ein Modul. Hier ist es wichtig, dass das Modul das ist, was Sie als Modul bezeichnet haben, was Sie als Einheit der Semantik betrachten. In diesem Fall geht es im Modul darum, wie wir Schlangen essen. Das Ergebnis dieses Moduls ist die letzte Methode, eatSnake, als wir Schlangen gegessen haben. Ich weiß nicht, warum wir Schlangen essen, aber wir können dies tun, weil wir dieses Modul geschrieben haben.



    Es war trivial, etwas interessanteres wird als Nächstes beginnen. Klassenschnittstelle Die Schnittstelle einer Klasse ist einfacher ihre öffentlichen Methoden, was sie hervorhebt, was wir von einem Objekt dieser Klasse von einem Objekt von außen erhalten können. Diese Klasse implementiert die getSnakeLength-Schnittstelle. Er kann uns die Länge der Schlange geben. Bitte beachten Sie, dass von außen kein Zugang zu privaten Feldern möglich ist. Der Zugriff von außen erfolgt nur auf die öffentliche Methode getSnakeLength.



    Dann aber eine sehr interessante Sache. Wir haben lange darüber geredet, wie man dieses Ding nennen soll, weil ich bei der Erstellung dieses Vortrags den Begriff „abstrakte Schnittstelle“ erdacht habe. Und ehrlich gesagt habe ich nie die normale Definition dieses Ansatzes und dieser Methode gesehen. In vielen Programmiersprachen können Sie jedoch abstrakte Schnittstellen erstellen und aufrufen, sobald es sich nicht um abstrakte Klassen und abstrakte Schnittstellen, sondern nur um Schnittstellen handelt. Es stellt sich das Homonym mit der Klassenschnittstelle heraus. Die Idee ist, dass eine abstrakte Schnittstelle eine Sammlung von Methoden ist, die etwas tun. Wenn wir eine Klasse erstellen, gehen wir von der Frage „Was ist das?“. Dies ist eine Schlange, die weiß, wie etwas zu tun ist, oder nicht weiß, wie. Sie kann einfach ihre Länge geben.

    Und wenn wir eine Schnittstelle erstellen, gehen wir davon aus, was sie tun soll und was sie können sollte. Und es stellt sich heraus, dass es eine sehr effektive Möglichkeit ist, den Unterricht zu erweitern. Wir können Klassen einige Möglichkeiten zuordnen, die mit Hilfe von Schnittstellen erweitert werden. Zum Beispiel kann das I-BEM-Framework so etwas tun, eine solche Geschichte mit abstrakten Schnittstellen ist in das Framework integriert. Viele Frameworks wissen leider nicht wie, aber eine mächtige Sache.

    Hier haben wir als Beispiel eine hörbare Schnittstelle erstellt, die sich anhören kann. Und ihre Definition ist eine abstrakte leere getNoise-Methode. Wir haben unsere Schlange mit der audiable-Klasse erweitert, ihre getNoise-Methode implementiert und unsere Schlange zischte. Die Inspiration für dieses Beispiel wurde mir von dem wunderbaren Buch von Eric Freeman und der Firma „Design Patterns“ gegeben.

    Jetzt werden wir versuchen, diese Beispiele etwas genauer zu betrachten.



    Aber zuerst wollen wir darüber sprechen, warum diese Beispiele gebraucht wurden. Und sie wurden für diese große Rutsche benötigt. Was hier geschrieben wird, ist so wichtig, dass ich es sogar zum gelben Titel trug. Man kann sagen, Mantra. Dies ist ein sehr wichtiges Prinzip, über das Sie beim Entwurf einer Architektur immer nachdenken sollten. Hoher Zusammenhalt, geringe Kopplung - starke Haftung, schwache Konnektivität. Es gibt ein Problem mit der Tatsache, dass das Wort Kohäsion und die Wortkopplung auf Russisch und so, und so übersetzt "Verbundenheit", speziell für dieses Prinzip, mit dem Wort Griff verstanden wurde.

    Die Idee ist dies. Ihre Blöcke sollten sehr kompakt und sehr fest miteinander verbunden sein. Sie müssen genau eine Funktion implementieren. Und untereinander müssen sie sehr leicht miteinander verbunden sein, so dass sie als Designer leicht kombiniert und montiert werden können. Und dann ist Ihre Architektur recht flexibel und ziemlich zuverlässig. Und einfach zu testen.

    Mal sehen, wie wir starke Adhäsion und schwache Konnektivität zwischen den Punkten erreichen, wie sie sagen.



    Spezialisierung Jeder Block löst nur ein Problem. Hier haben wir eine gute Illustration - eine Kindergestalterin. Wir haben jeden Block oder Satz von Blöcken. Sie haben alle ihre Form und Größe. Und wenn wir ein Haus bauen müssen, brauchen wir lange Bars. Wenn wir einen Ball bauen müssen, nehmen wir kurze Bars. Jede kleine Bar hat ihre eigene Funktion. Und diejenigen, die Konstrukteure gespielt haben, wissen, dass je einfacher die Form der Stücke ist, desto mehr können Sie daraus bauen. Aus diesem Zagogulin wird nichts aufgebaut oder nur das, was in der Anweisung beschrieben wird. Und wer braucht es?

    Das gleiche, Abstraktion. Es geht darum, dass die Abstraktion der Schnittstelle von der Implementierung abhängt. Die Idee ist, dass die Schnittstelle extern ist. So wie dies unsere Klasse ist, steht unser Block heraus. Die Art und Weise, wie sie mit anderen Blöcken interagiert, sollte sich nicht auf die interne Implementierung auswirken. Im Gegenteil - es passiert. In die andere Richtung - niemals. In guter Architektur. Die Bildung dieser Pickel beeinflusst hier beispielsweise nicht die Form des Blocks selbst. Wir wählen die Blockform separat aus und fügen die Unebenheiten darauf ein.



    Einkapselung. Fortsetzung des vorherigen Themas. In privaten Methoden, das heißt aus dem Inneren unserer Blöcke, erkennen wir die Bedeutung unseres Blocks, die Realisierung. Und die Schnittstelle, wie sie miteinander verbunden sind, ist öffentlich. Das heißt, in diesem Fall sind all diese Kreuze, Bindestriche und die Form selbst die Implementierung. Und die Beulen sind die Schnittstelle. Und gute Architektur sieht aus wie ein solcher Konstruktor.



    Oh, was für ein schreckliches Monster. Hier geht es um Wiederverwendungscode. Ursprünglich sollte dieses Monster zwar ein Beispiel für schlechte Architektur sein, aber es sollte genau betrachtet werden. Er ist wunderschön. Außerdem ist er sichtlich zufrieden mit dem Leben und läuft fröhlich auf seinen fremden Beinen. Vielleicht kann er sogar fliegen, oder er hat wenigstens wunderschöne Schmetterlingsflügel.

    Was ist die Idee? Wenn Sie eine Kamelimplementierung und einen Krokodilverkauf haben und ein Manager zu Ihnen kommt und sagt, dass ein Kamelkrokodil dringend benötigt wird. Sie schreiben kein Krokodilkamel separat. Du nimmst den Körper eines Kamels und trennst ihn von der ganzen Verwirklichung des Kamels. Nehmen Sie den Kopf eines Krokodils, trennen Sie es vom Krokodil und verwenden Sie Blöcke erneut. Warum ist das nötig?

    Wenn der Manager zu Ihnen zurückkommt und sagt, dass wir dringend nach Südamerika ausdehnen und Alligatoren vorhanden sind, müssen wir eine unregelmäßige Kieferform beibehalten, oder wenn das Krokodil den vierten Zahn nicht gleich hat, werden Sie nicht am gesamten Projekt herumfummeln Wo werden deine Krokodilköpfe kopiert? Weil Sie dort vielleicht ein Zebra-Bison-Krokodil haben. Nehmen Sie einfach Ihren Krokodilkopf, machen Sie eine Erweiterung aus der Alligatorkopfserie, geben Sie ihm die Parameter an, er bestimmt, welche Zähne für ihn lackiert werden sollen. Und alle. An einem Ort und nicht an allen Orten, an denen es verwendet wird.

    Hier wird die Zuverlässigkeit um ein Vielfaches erhöht, da in einem sehr seltenen Projekt garantiert jeder kopierte Kopf vergessen wird. Im Allgemeinen ist an solchen Kadavern nichts Schlimmes. Guter Cadavre, hilfreich.



    Jetzt betrachten wir Beispiele für fehlerhaften Code. Bitte beachten Sie, dass dies ein Pseudocode ist. Pseudocode ist etwas ähnlich wie TypeScript, aber immer noch Pseudocode. Versuchen Sie nicht, es auszuführen, es funktioniert nicht. Es ist möglich zu wiederholen, es lohnt sich nicht, diesen Code auszuführen, da hier syntaktische Konstruktionen verwendet werden, die TypeScript 2.7 nicht unterstützt, aber die Abbildungen sich als gut herausgestellt haben (jetzt gibt es mehr aktuelle Beispiele - ca. Rot.).

    Wir haben also eine Klasse Benutzer. Er hat einen Namen und ein Alter. Alles ist gut. Wir haben einen Benutzer mit dem Nachnamen, ich entschuldige mich für die verteilten Schriftarten. Benutzer mit Nachname, er hat Vorname, Alter und Nachname.

    Und wir haben eine printLabel-Methode. Wir geben ihm User. Wir schauen weiter, wenn wir eine Benutzerklasse haben, zeichnen wir den Namen und das Alter. Wenn Benutzerklasse Benutzer mit Nachname ist, dann Vorname, Nachname und Alter. Versuchen wir noch zu sehen, was hier schlimm ist.

    Code-Duplizierung schon? Viele verschiedene Code-Duplikationen, gut. Ja gut. Es gibt zwei Duplikationen des Codes, eine davon, dass wir einen UserWithSurname duplizieren, und die zweite ist, dass wir die printLabel-Methode duplizieren. Was gibt es sonst noch? Das ist richtig, ja, es geht nur darum, dass wir viel Code duplizieren, möglicherweise sogar noch mehr. Sonst noch was? Vererbung ist auch hier, und dies ist auch eine der Optionen. Hier gibt es zwei Probleme - keine Wiederverwendung, keine Spezialisierung. Wir haben auch über zwei Dinge gesprochen. PrintLabel klettert in private Methoden. Noch? Viertens was fehlt hier? Ja das ist es.

    Es gibt keine Spezialisierung, zwei Einheiten machen dasselbe. Es gibt keine Abstraktion, unsere Schnittstelle und Implementierung sind gemischt. Es gibt keinen eigentlichen Kapselungszugriff auf private Methoden. Die Wiederverwendung des Codes, etwa endlos wenn, was sehr viel werden kann, wurde sehr richtig gesagt. Mal sehen, wie es besser geht, aber wir werden es nicht tun.



    Wir erstellen die printLabel-Schnittstelle. Dies liegt nicht daran, dass iPrintLabel nicht auf das iPhone zurückzuführen ist, sondern auf die Schnittstelle. Und wir definieren eine einzige abstrakte Methode getText. Erstellen Sie eine Benutzerklasse, die iPrintLabel implementiert. Er hat wirklich private Felder, Namen und Alter, und eine einzige öffentliche Methode, den gleichen getText von iPrintLabel, in dem wir ehrlich von privaten zu privaten Feldern wechseln, dies ist erlaubt und sogar gefördert. UserWithSurname wird tatsächlich von der User-Klasse geerbt. Wir müssen nur den Nachnamen definieren und getText neu definieren. PrintLabel wird jedoch sehr einfach sein. Es benötigt iPrintLabel und gibt einfach getText aus.

    Das Schöne daran ist, dass, wenn eine Abstraktion erscheint, die Schnittstelle separat ist und die Implementierung separat ist. Kapselung erscheint. Spezialisierung, bitte, wir haben die Erbschaft dafür gemacht. Und mit der Wiederverwendung des Codes ist im Allgemeinen alles in Ordnung, da wir alles drucken können. Die Hauptsache besteht darin, die iPrintLabel-Schnittstelle zu erweitern, und wir können nicht denken, dass es gedruckt wird, nicht gedruckt wird. Wir werden die printLabel-Methode nicht mehr berühren. Hier ist ein guter, sehr einfacher, kurzer Weg, um die Architektur in ein paar zusätzlichen Codezeilen zu verbessern.

    An diesem Punkt enden wir mit der Theorie. Mit der Theorie von allem, weil das, was wir gerade beschrieben haben, nicht nur für das Frontend gilt, für alles im Allgemeinen. Und wir wenden uns den architektonischen Ansätzen zu und gesondert den architektonischen Ansätzen, die im Frontend verwendet werden und nützlich, gebraucht und gefunden werden.



    Wie funktioniert die durchschnittliche Webanwendung? Es gibt einen Server. Innerhalb des Servers ist eine Art Back-End-Architektur implementiert. Einige API bleiben davon ab, zum Beispiel kann es sich um eine REST-API oder nicht um ein REST handeln. Alles in allem - der Client und der Server - ist auch eine Implementierung des Client-Server-Architekturansatzes. Weil wir reine Serveranwendungen haben können, reine Clientanwendungen, jedes PowerPoint, von dem aus alles abgespielt wird. Dies ist eine reine Client-Server-Anwendung.

    Als nächstes betrachten wir das Frontend genauer. Das Frontend besteht aus einigen großen Blöcken. Jeder Block ist irgendwie implementiert, und mit dieser Implementierung können Sie große Blöcke miteinander verknüpfen. Innerhalb des Moduls ist es auch irgendwie implementiert. Innerhalb der Modulmethode. Diese Methode hat auch eine Architektur. Architektur ist also eine Hierarchie. Auf jeder Ebene existiert es, zumindest auf der Ebene der Deklaration einer Variablen. Dies kann auch ein Stück Architektur sein. Klein

    Wir werden heute über die oberste Ebene der Front-End-Architektur sprechen, d. H. Wie große Module angeordnet sind, wie Daten von Benutzer zu Server, von Server zu Benutzer übertragen werden, und ein wenig über die Implementierung in Modulen, wie diese implementiert werden sollen Dies hat geschaffen.

    > Client-Server ( Client-Server )
    > Komponente ( komponentenbasiert )
    > Ereignisgesteuert ( Ereignisgesteuert )
    > REST ( Representational State Transfer )
    > Modellansicht - * ( MVC , MVP , MVVM )
    > Unidirektionale Datenflüsse ( Flux )

    Dies sind die architektonischen Ansätze. Einige davon haben wir heute erwähnt. Client-Server-Architektur; Komponentenarchitektur, eine ihrer Variationen ist Ihnen aus React bekannt, hoffe ich, ist vertraut. Event, das seltsamerweise auch jedem bekannt ist, basiert auf fast allen Betriebssystemen für Personal Computer. REST, was wir auf dem Server lieben, und die letzten beiden, mit denen wir uns im Detail vertraut machen werden, sind das Front-End. Wir arbeiten mit der Modelldarstellung * und unidirektionalen Datenströmen.

    Beginnen wir mit MV *. Warum ein Sternchen? Die Geschichte heißt voller Schmerz und Wut. Es war einmal in den 80er Jahren, als ein bemerkenswerter MVC-Architekturansatz erfunden wurde. M - Modell, V - View, C - Controller. Der Ansatz war sehr bequem. Hat es überhaupt für Konsolenanwendungen erfunden. Als sich jedoch Webtechnologien zu entwickeln begannen, stellte sich heraus, dass es manchmal notwendig war, das MV-Modell gut ist und der Controller nicht so implementiert ist, wie er begann. Infolgedessen gab es so viele verschiedene Variationen bei der Implementierung von Model-View - etwas, das zu Verwirrung führte, weil alle es als MVC bezeichneten. Denn wenn das MV-Modell da ist, dann ist das dritte der Controller, egal, was wir da eigentlich gestopft haben.

    Dann stellte sich heraus, dass die Leute durch MVC völlig andere Dinge verwirrt sind und meinen. Ungefähr vor einem Jahr haben wir begonnen, diese Terminologie aktiv zu teilen und für jede Implementierung dieses Ansatzes einen Namen zu machen. Wie auch immer, dieses MV * erschien. Ich habe auch den Begriff MVW im Internet gesehen, wo W - Was auch immer. Nun, wir wenden uns tatsächlich an MVC-Technologien.



    Wie sind sie angeordnet? Die Idee ist, dass wir ein Modell haben, das Daten speichert. Sie sind normalerweise viel. Es gibt eine Art Ansicht, die dem Benutzer diese Daten anzeigt. Sie auch in der Regel viel. Und eine dritte Komponente, die als Vermittler dient, bindet die Daten und die Anzeige. Hier ist der Benutzer in der oberen rechten Ecke mit all dem, was funktioniert.



    MVC, was alles angefangen hat, ist das ferne 1980-Jahr, Smalltalk. Aber in dieser Form existiert es in manchen Rahmen noch. Nicht in einigen, ganz in vielen. Was ist die Idee? Der Benutzer arbeitet direkt mit der Ansicht und dem Controller. Er gibt Daten in einige Felder in der Ansicht ein, drückt die Senden-Taste und die Daten gelangen an die Steuerung. Dies ist eine Formulareinreichung. Ehrlich gesagt, eine solche Formulareinreichung über die Schaltfläche "Senden", die ich seit langem kenne, hoffe ich.

    Wir schauen Der gelbe Pfeil vom Benutzer zum Controller ist der Benutzer, der die Daten über die Schaltfläche "Senden" an den Controller übermittelt. Grüner Pfeil - Kontrolle an dieselbe Stelle übergeben. Der Controller betrachtet diese Daten. Vielleicht verarbeitet er sie irgendwie, es gibt bereits die Feinheiten der Implementierung und schickt sie zum gewünschten Modell. Der Controller wählt das zu sendende Modell aus. Sendet mit einem grünen Pfeil zur Kontrolle, sendet mit einem gelben Pfeil Daten.

    Das Modell verarbeitet auch die Daten. Vielleicht bestätigt sie sie. Vielleicht legt sie sie in die Basis. Kurz gesagt, das Modell weiß, was mit ihnen zu tun ist. Das Ergebnis sind in der Regel neue Daten. Zum Beispiel können wir dem Benutzer mitteilen, ob er sich angemeldet hat oder nicht, und das Modell hat das Kennwort mit einem Login überprüft. Danach überträgt das Modell die Steuerung erneut an die Steuerung, sodass die Steuerung die anzuzeigende Ansicht auswählt. Und die Daten gehen direkt zur Ansicht. Wie können Sie dies im Allgemeinen tun, wie kann das Modell die Daten an die Ansicht senden?



    Sehr einfach. Wenn sich Controller und Modell im Backend befinden und die Ansichtsvorlage serverseitig ist. So werden Ruby on Rails-, ASP.NET- und Django-Frameworks generell überall dort entworfen, wo Sie Server-Templates schreiben, und der empfangene HTML-Code kommt auf den Client, und die Daten werden auch zurückgegeben, höchstwahrscheinlich ist dies der Ansatz. Was sind unsere Probleme hier? In einer Einzelseitenanwendung wird so etwas nicht erstellt. Wir kamen ständig zum Server, gingen zum Server, die Seite wird neu geladen. Zweitens ist es überhaupt nicht klar, wo die Client-Validierung und generell clientseitiges JavaScript, AJAX und all das gepusht werden soll. Denn wenn wir schnell etwas wollen, gibt es keinen Platz. Bei diesem Ansatz funktioniert es einfach nicht oder es funktioniert so, dass es nicht besser funktioniert.

    Die letzte Zeile hier ist eine interessante Geschichte mit Wurzeln, die scheinbar bis 2008 zurückreicht. Die Frage war: Wo soll Geschäftslogik gespeichert werden - auf dem Modell oder in der Steuerung? Es gab diejenigen, die sagten: „Wir behalten die Geschäftslogik im Controller, da es praktisch ist, die Daten sofort an das Modell gesendet werden. Der Controller selbst zahlt sich aus, prüft, ob etwas vorhanden ist, und sendet einen Fehler. “ Es gab die, die sagten: "Das Ergebnis sind dumme, dumme hässliche Controller, dicke dumme, hässliche Controller." Sie sind wirklich groß geworden. Und sie sagten, dass die Geschäftslogik im Modell sein sollte und der Controller dünn, leicht sein sollte, die Daten durchlaufen und das Modell selbst verarbeitet werden sollte. In der ersten Version des Modells stellt sich im Allgemeinen nur eine API für die Datenbank heraus.

    Wie meiner Meinung nach wirklich? In der Tat müssen Sie ihre Aufgaben beobachten. Wenn Sie eine Verbindung zwischen einer Ansicht und einem Modell immer eins zu eins haben, ist eine Ansicht ein Modell. In diesem Fall ist es für Sie zweckmäßig, Geschäftslogik in den Controllern auszuführen und ein einfaches, sauberes Modell zu erstellen, das eine API für die Datenbank darstellt. Wenn Ihre Ansichten und Modelle sich überschneiden können und eine Ansicht von vielen Modellen abhängt, funktioniert das Modell mit vielen Ansichten. Es ist praktisch, wenn Sie viele dünne Controller haben und diese in jeder beliebigen Reihenfolge multiplizieren. Es ist Ihnen egal, wie viele es sind.

    Es muss gesagt werden, dass in der Welt, wie es scheint, der zweite Gesichtspunkt mit Geschäftslogik in Modellen gewonnen wurde. Das heißt, diese dummen, dummen hässlichen Controller scheinen weniger aktiv zu sein. Signale können Sie beobachten, dass in der Dokumentation für ASP.NET das Framework im Jahr 2013 Geschäftslogik in den Controllern enthielt. Und in den neuesten Versionen 2014 - in Modellen. Es war ein sehr interessanter Moment, als es sich veränderte.

    Was MVC hat Probleme. Wir haben sie schon gesprochen, aber wir werden sprechen. Tests sind nicht klar, wie die Client-Validierung implementiert werden kann, aber schwierig, AJAX ist auf der Seite geschraubt, Sie müssen etwas tun. Kommen Sie mit einer Lösung. Die Lösung wurde MVP genannt, und ja, Sie können MVP in einem Framework mit dem Text treffen, dass es sich um MVC handelt. Zum Beispiel das Backbone MVP-Framework. Über ihn wurde in der Dokumentation 2011-2012-2013 lange Zeit geschrieben, dass es sich hierbei um ein MVC-Framework handelt.



    Model-View-Presenter. Sein Schema ist viel einfacher. Es gibt Modelle. Sie interagieren miteinander. Daten an den Presenter übergeben, Presenter sendet sie an die Ansicht, zeigt sie dem Benutzer. Und zurück Der Benutzer fährt etwas in die Ansicht ein, drückt einen Knopf, Presenter überwacht es, AJAX sendet es an das Modell oder fügt es in das Modell ein und sendet das AJAX-Modell an den Server. Das heißt, hier ist alles schon viel einfacher und linearer, aber ohne Server-Templates gibt es bereits Schwierigkeiten. Wenn Sie einen Server wünschen, wird dieses System kompliziert.



    Lass uns vergleichen. Schauen wir uns das erste Bild an, in dem wir versuchen, eine sehr einfache Sache zu implementieren - das Senden von Daten von der Eingabe zum Modell. Wir haben etwas eingegeben, einen Knopf gedrückt, es sollte im Modell erscheinen, das Modell wird etwas damit tun und uns sagen, dass etwas passiert ist. Wir fuhren ein: „Mein Name ist Vasya“, sie klickten auf OK. Wenn wir eine Client-Validierung wünschen, geschieht dies hier, durch Abfangen, in besonders schweren Fällen, in der Tat, indem ein Klick durch event.preventDefault () abgefangen wird. Und irgendwo ist eine Null-Client-Validierung auf der Seite.

    Dann senden wir die Daten ehrlich über das Anmeldeformular an den Controller. Die Daten gehen in das Modell, das Modell legt sie ein, verarbeitet, sieht aus. Sagt uns, dass die Daten akzeptiert werden, Sie wirklich Vasya. Der dritte Pfeil - die Steuerung geht an die Steuerung, das Modell informiert die Steuerung darüber, dass das Etikett "Mein Name ist Vasya" angezeigt wird. Der Controller wählt die entsprechende Ansicht aus und zeigt das Etikett an. Und die Daten lauten "Mein Name ist Vasya", der vierte Pfeil, der gelbe, das Modell legt dort ab. Die Frage ist, wie man es testen kann. Nur Momentaufnahme. Auf andere Weise. Es gibt nicht einmal Funktionsprüfungen zu schreiben.

    Die zweite Option bereits mit MVP. Wir fuhren in "Mein Name ist Vasya" ein, wir haben auf OK geklickt. Pfeil an Nummer eins, wenig grün, - Kontrolle ging an Presenter. Moderator sagte: Taste gedrückt. Der Moderator schaut zu, Pfeil Nummer zwei, blau, bitte beachten Sie, dass es sich um eine Datenanfrage handelt. In einem klassischen MVP werden keine Daten aus einer Ansicht an einen Presenter gesendet, sondern eine Anforderung von Presenter nach Daten. Dies ist viel sauberer, da der Presenter möglicherweise bereits im Voraus weiß, dass er die Daten nicht benötigt, alles ist immer noch schlecht.

    Der dritte Punkt zu Presenter ist die ehrliche JS-Validierung. Wir können es schon ruhig schreiben, das ist ein besonderer Ort dafür. Der vierte Pfeil - die Daten gehen an das Modell, das Modell zum Beispiel legte sie in die Datenbank, sagte: "Alles ist in Ordnung, ich lege es." Der fünfte Pfeil, Sie sehen, es ist gestreift, ich hoffe, es ist gelb-grün gestreift - sowohl die Kontrolle als auch die Daten kamen zum Presenter zurück. Das Modell sagte: „Ich habe es formuliert“. Presenter selbst stellte fest, dass sobald die Daten in die Datenbank eingegeben wurden, bedeutet es, dass angezeigt werden muss, dass alles in Ordnung ist. Die Daten werden gespeichert. Und der sechste Pfeil - sie schickten es zur Ansicht, möglicherweise zu einem anderen, aber dann zog ich die zweite Ansicht nicht.

    Was wir hier haben, ist ein Plus. Die JS-Validierung hat ihren rechtmäßigen Platz eingenommen und alles war gut damit, AJAX ist auch in Ordnung, es könnte der vierte Pfeil sein, zum Beispiel wenn das Modell auf dem Server ist oder das AJAX-Modell selbst zum Server geht. Und schließlich können wir Presenter sicher testen und Funktionstests darauf schreiben.



    Zweitens, was haben wir außer vereinfachten Tests noch schwarze Zahlen geschrieben? Wir haben eine Trennung von der visuellen Anzeige und ihrer Arbeit erhalten. Das heißt, wir können immer noch eine Momentaufnahme in die Ansicht schreiben und wir können Tests separat mit dem Presenter schreiben. Wir können Presenter reparieren und nicht View berühren und umgekehrt. Wir haben die Spezialisierung verbessert. So werden Frameworks wie Angular1, Backbone, Ember, Knockout früherer Versionen angeordnet. Früher gab es viele von ihnen, nur einen harten Wettbewerb.

    Was sind die Funktionen? Der Präsentator ist bereits auf dem Client platziert, das Modell kann vorhanden sein und dort wird die Einzelseitenanwendung leise gemacht. Es kann besser sein, aber es handelt sich um eine Einzelseitenanwendung, oder es wurde zumindest Die Interaktion mit dem Server durch AJAX ist gut. Kundenvalidierung vor Ort. Es scheint, dass alles gut ist, warum weiterdenken?

    Zumindest MVVM wurde jedoch erfunden. Auch eine interessante Sache.



    Im Wesentlichen handelt es sich hierbei um eine Presenter-Implementierung mit Hilfe des Frameworks. Wenn Sie den ersten Presenter, den zweiten Presenter, den fünften Presenter geschrieben haben, ist es oft der Fall, dass sie alle gleich sind. Und sie stricken nur die Ansicht und das Modell. Wie Sie sehen, funktioniert es wie MVP.



    Und so viele Frameworks lösten gerade diese verbindlichen Aufgaben. Was sind die vorteile Wir müssen keinen zusätzlichen Code schreiben. Und das beschleunigt die Entwicklung wirklich. Was sind die Nachteile? Die Verbindung zwischen dem Modell und dem ViewModel wurde verbessert.

    Das heißt, Probleme entstehen dort gerade wegen der starken Vernetzung, daher kommt es manchmal vor, dass MVVM nicht verwendet wird. Ich kenne mich zum Beispiel mit MVVM im i-BEM-Framework aus, das wir manchmal verwenden und manchmal nicht verwenden, weil es unpraktisch ist, ein zu starres Unentschieden. Es gibt jedoch Microsoft Silverlight, das auf dieser Technologie basiert, und sie sagen: gut. Ich weiß es nicht, habe es nicht versucht.

    Warum ist es passiert, dass neben MVP und MVVM etwas anderes entstanden ist, das Ihnen alle im Wort redux bekannt ist, warum unidirektionale Datenflüsse entstanden sind.



    Wir schauen auf das richtige Bild. Wir haben dieses Problem regelmäßig mit MVP. Angenommen, wir haben ein komplexes System, nicht eins zu eins, viele Ansichten, viele Modelle. Sie sind alle miteinander verbunden. Ansicht von oben, gelblich, Modell geändert. Das Modell hat ein anderes Modell geändert. Die untere gelbe Ansicht hat sich geändert. Die untere Ansicht hat auch das Modell geändert. Alle zusammen veränderten die zentrale rote Sicht, und etwas Unverständliches geschieht darin.

    Facebook sah sich dem Problem gegenüber, als sie ständig einen Fehler aufgrund von ungelesenen Popup-Meldungen hatten. Das heißt, der Benutzer sieht "Sie haben eine ungelesene Nachricht", wird geöffnet, aber nicht. Weil zwei Ansichten zusammen den Status dieser Ansicht korrigierten ... Im Allgemeinen wurde der Status der Ansicht aus zwei verschiedenen Quellen korrigiert, und wer recht hat, ist nicht klar. Sie haben es entschieden, der Fehler ist wieder aufgetreten, sie haben wieder entschieden, der Fehler ist wieder aufgetreten. Am Ende sind sie müde, und sie beschlossen, das Problem radikal zu lösen, entschuldigen die Tautologie und sorgen nur dafür, dass der Zustand der Ansicht deterministisch ist.

    Das MVP-Problem liegt im Nicht-Determinismus des Systemzustands. Wir können nicht immer vorhersagen, in welchem ​​Zustand es sich jetzt befindet und wer zuerst da war, wer es korrigiert hat. Flux hat dieses Problem genetisch gelöst. Er kann das nicht haben. Mir wurde hier lange gesagt, dass die Idee eines unidirektionalen Datenflusses in der Luft lag, das stimmt. Und dieses Konzept wurde natürlich lange vor Facebook erfunden, lange vor 2013, als es veröffentlicht wurde. Aber sie haben, wie sie sagen, patentiert, zuerst einen Spreadshit veröffentlicht, den wir gerade mit so etwas hatten, benutzen es.



    Schauen wir uns Flux genauer an. Die Idee hier ist diese. Wir haben einen Store, und dieser Store ist ein Data Warehouse, es ist die einzige Wahrheit für unsere Anwendung. Der Rest ist nicht wahr. Wie es funktioniert Wenn wir uns zuerst den Arbeitszyklus anschauen, fängt das normalerweise an, dass der Benutzer etwas getan hat, dh die Ansicht funktioniert. Die Ansicht erstellt eine Aktion. Bitte beachten Sie, dass die Aktion ohne Bild ausfüllt. Warum so? Weil es eine Struktur ist. Es ist keine Klasse, kein Objekt, es ist nichts Kluges. Dies ist eine Struktur. Im Web, in JavaScript, können wir es schreiben, es ist nur dieses abstrakte Objekt.

    Die Sichtstruktur wird angelegt, an den Blockverteiler übergeben. Der Dispatcher löst einen Rückruf aus. Er sagt also: „Rufe die Funktion auf, die ich anrufen soll, wenn Action passiert. Sagte, um den Laden anzurufen. " Das heißt, die Store-Methode des Dispatchers wird aufgerufen. Die Methode wird aufgerufen. Die Methode wird aufgerufen, sie stellt sich im Store heraus. Store sieht aus, was zu ihm gekommen ist, ändert sich irgendwie. Er ändert seinen Zustand. Und er ist der einzige, der seinen Zustand ändern kann. Niemand sonst tut es. Das heißt, er ist die einzige Quelle der Wahrheit. Danach hat Broadkastit alle Ansichten daran gebunden, alle Komponenten daran gebunden: "Ich habe mich geändert, gehen Sie für die Daten."

    Ansichten gehen nach den Daten, und dann beginnt ein interessanter Moment. Im klassischen Flux wird die Ansicht, wie sie auf Facebook dargestellt wird, vollständig neu gezeichnet.



    Hier ist unser Werkzeug mit einem Etikett und einem Knopf. Wie arbeitet sie? Schauen Sie sich Artikel Null an. Auch hier Null. Er ist der blaue Pfeil unten, Anmeldungsrückruf. Das ist was zuerst passiert.

    Der Laden im Dispatcher ruft an: "Registrieren Sie sich bitte, mein Rückruf, was werde ich tun, wenn die Aktion auf Sie zukommt". Es ist passiert Dann können wir mit der Anwendung arbeiten. Wir haben einen Knopf gedrückt und eine Struktur erstellt. Beachten Sie, dass die Aktion neben den vom Benutzer eingegebenen Daten, beispielsweise Vasya, auch den Metadatentyp hat. Ein sehr wichtiger Punkt ist, dass die Aktion selbst übermittelt, dass sie für die Aktion bestimmt ist, der Disponent sich jedoch nicht darum kümmert. Er wirft die ganze Action-Sendung. Mit dem ersten Pfeil wird die Methode aufgerufen.

    Der Dispatcher ruft die Methode im Wesentlichen den Aktionsauslöser auf und übergibt dieselbe Aktion dort. Beim Action-Auslöser erfolgt ein Rückruf, den wir am Punkt Null registriert haben. Hier ist der rote Pfeil, dies ist ein Rückruf mit Rückruf. Store nimmt diese Daten an, schaut sich an, was, ja, Namensänderung, dann ändere ich mich im Namensfeld in Vasya und schicke sie an das Back-End. Irgendwie bestätigt der Store, dass der Store weiß, was zu tun ist . Als nächstes ist der violette Pfeil ein Änderungsereignis. Wir haben uns verändert. Jeder weiß, dass sich unser Shop verändert hat.

    Des Weiteren ein kleines Feature des klassischen Flux, das für diejenigen, die mit Redux gearbeitet haben, ungewöhnlich ist, genauer gesagt, sogar mit React und nicht mit Redux. Ansichten folgen den Daten. Sie gehen in den Laden und sagen: "Ich habe dieses Feld, dieses Feld und dieses Feld hier." Wir sind daran gewöhnt, dass im Gegenteil alles zu Ansichten kommt, wenn Sie mit React, Redux oder so ähnlich gearbeitet haben. Und der sechste Punkt, komplett neu gezeichnet.

    Schauen wir uns dieses Schema an und finden Sie einen Engpass. Neu zeichnen Vollständiges Neuzeichnen, weshalb Flux nach 2013 aktiv eingesetzt wurde. Wann ist etwas entstanden? Was hat es erlaubt? Virtuelles Zuhause. Ein virtuelles Haus, in dem Sie nur dann neu zeichnen können, wenn es wirklich notwendig ist.



    Lassen Sie uns ein wenig beiseite treten und Ihnen etwas über React erzählen, das auf diese Weise sehr erfolgreich in Kombination mit Flux die Welt gemacht hat, die wir heute kennen, wenn diese Technologie am beliebtesten ist.

    Gleiches 2013, gleiches 2013, gleiches Facebook. Anfänglich wurde React im Allgemeinen erfunden, wie aus den Ansichten in MVC, MVP, Variationen hervorgeht. Und es kann wirklich dort verwendet werden. Was ist ihre Kraft? Erstens erlaubt es ein virtuelles Haus, wie es richtig gesagt wurde, nicht das eigentliche Haus neu zu zeichnen, weil es eine sehr schwierige Operation ist, sondern das virtuelle. Und nur wenn es tatsächlich eine Änderung gab, zeichnen wir die Komponente neu, mit dem Ergebnis, dass alles viel schneller arbeitet, als es sein könnte.

    Und - reine Immunitätskomponenten. Dies ist der Mechanismus der Eigenschaften. Die Implementierung ist auch eine Rakete, mit der Sie Komponenten erstellen können, die keinen eigenen Zustand haben. Und wenn Sie in diese Architektur schreiben, ist es sehr korrekt, Komponenten zu erstellen, die sauber, ohne Status und ohne Status sind. Sie haben nur die Daten, die aus dem Laden stammen, und er zeichnet sie. Es ist praktisch, sie zu testen, sie brechen sehr selten. Was statisch ist, ist ziemlich schwer zu brechen und das Testen ist einfach.

    Anwendungen kombiniert mit Flux-Architektur sind leistungsstark. Wahrscheinlich wissen viele Leute, dass dies wirklich eine mächtige Sache ist. Welche Bedeutung sollte unbedingt erwähnt werden? Neben React Redux gibt es viele weitere Bundles. Und wahrscheinlich wissen Sie, dass es einen zweiten Angular gibt. Dies ist auch eine Kombination aus einem reaktiven Framework und einer Flux-Architektur. Es gibt Vue, es gibt andere Implementierungen von Flux neben Redux - Fluxxor, MobX usw. Es ist nicht nötig, auf React Redux einzugehen. Der gleiche Vue ist beispielsweise für das Erstellen kleiner Anwendungen bequemer als React Redux. Es ist viel leichter.



    Wie kann man zwischen all dieser Vielfalt wählen? Es scheint, dass jetzt nur Redux reagieren und alles gut ist. Nun, Vue, in Ordnung. Eigentlich nein. Wenn Sie eine einfache Website mit statischen Seiten oder sehr einfachen Client-Eingaben haben, ist es sehr viel einfacher, das MVC-Framework schnell zu starten. Weil Sie wahrscheinlich ein Admin-Panel mit einer Menge Daten und einer Anzeige haben. Und es ist keine Interaktion erforderlich. Bei manchen React Redux wirst du töten, um es zu schreiben.

    MVP / MVVM-Frameworks haben auch ihre Nische. Es ist jetzt selten, weil Anwendungen häufiger benötigt werden - mehrseitig, mit dynamischen, aber recht einfachen Daten. Keine Einzelseitenanwendung, sondern Mehrseitenanwendung. Einige Daten vom Benutzer kommen noch. Es wäre zum Beispiel praktisch, einfache Wiki-Seiten zu erstellen, ohne dabei sehr komplexe Formatierungen und Interaktivität zu erfordern. Unprätentiös, bei MVP wäre das ziemlich bequem.

    Nun ist der häufigste Fall für uns eine Einzelseitenanwendung und komplexe Logik, viel Interaktion zwischen Komponenten, alle Arten von intelligenten Eingaben usw. Dies ist Flux mit einem virtuellen Zuhause. React Redux, View, Angular, MobX, Fluxxor usw.

    Fazit. Literarisch.

    > MVC: Smalltalk-80 , Allgemeines MVC , ASP.NET , MVC im Web
    > MVP: MVP vs. MVC , GUI-Architektur , Backbone , Angular1
    > MVVM: MS Silverlight , BEM und i-BEM
    > Flux: Hexlet-Blog , Flux for dumme Leute , Flux-Beamter , ReactJS , VueJS
    > Andere: Stoyan Stefanov, “Javascript. Templates , Eric Freeman ua, Design Patterns , D.Garlain, M.Shaw, "Eine Einführung in die Softwarearchitektur"(1994), E.Dijkstra "GOTO-Aussage als schädlich" (1968)

    Über MVC, MVP, MVVM können Sie viele Dinge lesen. Es ist klar, dass es zunächst eine Dokumentation für die entsprechenden Softwareanwendungen gibt. Es gibt viele Erklärungen zu Flux im Internet. Lesen Sie, es könnte klarer sein. Die interessanteste Linie ist wahrscheinlich die letzte. Sie im Allgemeinen über alles. Javascript Vorlagen Wenn Sie plötzlich in der Welt von ES5 leben müssen, dann im ersten Buch „JavaScript. Templates “Sie werden feststellen, wie praktisch es ist, eine Architektur ohne all diese ES6-Features zu erstellen - die natürlich vorhanden sind, aber manchmal müssen Sie auch ohne sie auskommen.

    Eric Freeman, Design Patterns. Sehr nützliches Buch. Es gibt Beispiele in Java, aber das sollte Sie nicht erschrecken. Vieles, was dort geschrieben wird, wird auch in Flux verwendet, wie Sie später feststellen werden. Und das wird in MVP verwendet, und das ist da. Aber ich kann ein solches Muster in diesem Block verwenden, der Bilder auf meinen Bildschirm zeichnet. Sehr nützliches Buch und leicht zu lesen.

    Das gleiche Buch, David Gerlan und Mary Shaw, "Einführung in die Softwarearchitektur". Es ist natürlich veraltet, aber was heißt zuverlässig. Und ich kann den Artikel von Edsger Dijkstra nur wärmstens empfehlen: "GOTO-Operator wird als schädlich betrachtet". Es ist wie eine Arithmetik. Wahrscheinlich ohne irgendwo.

    Hausaufgaben. Es wird interessant sein. Wir werden unseren Rahmen schreiben. Ich denke, jeder mehr oder weniger erfahrene Programmierer wird sagen, dass ihm früher oder später dieser Gedanke gekommen ist. Sie werden aufgefordert, mindestens ein wenig Flux, die eigentliche Geschichte mit der Beschriftung, der Schaltfläche und der Eingabe für Flux zu schreiben. Sie müssen die Implementierung von Serverkomponenten nicht schreiben - es reicht aus, nur auf der Konsole zu drucken, die wir vorgeben, etwas an den Server zu senden. Die Implementierung eines vollständigen Neuzeichnens des virtuellen Startbildschirms ist auch nicht zum Schreiben erforderlich. Sie können nur ein Stück neu zeichnen und so tun, als sei die Komponente vollständig neu gezeichnet worden. Fragen, Wünsche, können Sie hier schreiben . Herzlichen Dank.