Detaillierte Erläuterung des Front-End-Systems von Vue sowie der Trennung von Front-End und Back-End

Überblick

Vue (ausgesprochen /viu/, ähnlich wie „view“) ist ein fortschrittliches Framework zum Erstellen von Benutzeroberflächen, das im Februar 2014 veröffentlicht wurde.

Anders als andere große Frameworks ist Vue darauf ausgelegt, Schicht für Schicht von unten nach oben angewendet zu werden. Die Kernbibliothek von Vue konzentriert sich nur auf die Ansichtsebene, was nicht nur den Einstieg erleichtert, sondern auch die Integration in Bibliotheken von Drittanbietern (wie z. B.: vue-router:跳轉, vue-resource:通信, vuex:管理) oder bestehende Projekte vereinfacht.

Offizielle Website: https://cn.vuejs.org/v2/guide/

Front-End-Wissenssystem

Bis zum echten „Internet Java Full-Stack Engineer“ ist es noch ein weiter Weg, und „Ich bin ein großer Front-End-Experte“ ist ein Pflichtkurs, den man nicht umgehen kann. Der Hauptzweck dieser Kursphase besteht darin, meinen Java-Backend-Programmierern beizubringen, das Frontend zu erkennen, zu verstehen und zu beherrschen, um so einen weiteren Schritt auf dem Weg zu einem „Internet-Java-Full-Stack-Programmierer“ zu machen.

Drei Elemente des Frontends

• HTML (Struktur): Hypertext Markup Language, die die Struktur und den Inhalt einer Webseite bestimmt
• CSS (Ausdruck): Cascading Style Sheets, die den Präsentationsstil einer Webseite festlegen
• JavaScript (Verhalten): ist eine schwach typisierte Skriptsprache, deren Quellcode nicht kompiliert werden muss, sondern vom Browser interpretiert und ausgeführt wird, um das Verhalten der Webseite zu steuern.

Präsentationsschicht (CSS)

CSS ist eine Auszeichnungssprache und keine Programmiersprache. Sie können daher keine Variablen anpassen oder auf sie verweisen. Mit anderen Worten bietet es keine Syntaxunterstützung. Die Hauptmängel sind folgende:

• Die Syntax ist nicht leistungsfähig genug. Sie lässt sich beispielsweise nicht verschachteln, was bei der modularen Entwicklung zu vielen sich wiederholenden Selektoren führt.
• Es gibt keinen Mechanismus zur Wiederverwendung von Variablen oder sinnvollen Stilen, sodass logisch verwandte Attributwerte wiederholt in Form von Literalen ausgegeben werden müssen, was die Wartung erschwert.

Für uns ist dadurch viel unnötiger Mehraufwand entstanden. Um dieses Problem zu lösen, verwenden Front-End-Entwickler ein Tool namens CSS-Präprozessor, um einen in CSS fehlenden Wiederverwendungsmechanismus für die Stilebene bereitzustellen, redundanten Code zu reduzieren und die Wartbarkeit des Stilcodes zu verbessern. Verbessert die Effizienz der Front-End-Entwicklung im Hinblick auf den Stil erheblich.

Was ist ein CSS-Präprozessor?

Der CSS-Präprozessor definiert eine neue Sprache. Die Grundidee besteht darin, mithilfe einer speziellen Programmiersprache einige Programmierfunktionen zu CSS hinzuzufügen, CSS als Ziel zum Generieren von Dateien zu verwenden und Entwickler müssen diese Sprache dann nur noch zum Codieren von CSS verwenden. Einfach ausgedrückt bedeutet dies: „ Verwenden Sie eine spezielle Programmiersprache, um den Stil der Webseite zu entwerfen, und konvertieren Sie ihn dann mithilfe eines Compilers in eine normale CSS-Datei, um ihn im Projekt verwenden zu können.“

Was sind die häufig verwendeten CSS-Präprozessoren?

• SASS: Basierend auf Ruby, vom Server verarbeitet, leistungsstark. Hohe Analyseeffizienz. Sie müssen die Sprache Ruby erlernen, deren Einstieg schwieriger ist als der von LESS.
• LESS: Basiert auf NodeJS, wird vom Client verarbeitet und ist einfach zu verwenden. Die Funktionen sind einfacher als bei SASS und die Analyseeffizienz ist auch geringer als bei SASS, reicht aber für die tatsächliche Entwicklung aus. Daher empfiehlt unser Backend-Personal, bei Bedarf LESS zu verwenden.

Verhaltensebene (JavaScript)

JavaScript ist eine schwach typisierte Skriptsprache. Ihr Quellcode muss nicht kompiliert werden, bevor er zur Ausführung an den Client gesendet wird. Stattdessen werden die Zeichencodes im Textformat zur Interpretation und Ausführung an den Browser gesendet.

Native JS-Entwicklung

Native JS-Entwicklung bedeutet, dass wir gemäß dem **[ECMAScript]**-Standard, abgekürzt ES, entwickeln und dessen Besonderheit darin besteht, dass alle Browser ihn unterstützen. Zum Zeitpunkt dieses Blogbeitrags wurden die folgenden Versionen des ES-Standards veröffentlicht:

• ES3
• ES4 (intern, nicht offiziell veröffentlicht). ES5 (von allen Browsern unterstützt)
• ES6 (häufig verwendet, aktuelle Mainstream-Version: Webpack-Pakete in ES5-Unterstützung!)
• ES7
• ES8
• ES9

Der Unterschied besteht in der schrittweisen Hinzufügung neuer Funktionen.

TypeScript Microsoft Standard

TypeScript ist eine kostenlose Open Source-Programmiersprache, die von Microsoft entwickelt wurde. Es handelt sich um eine Obermenge von JavaScript und fügt der Sprache im Wesentlichen optionale statische Typisierung und klassenbasierte objektorientierte Programmierung hinzu. Geleitet von Anders Hejlsberg (Vater von C#, Delphi, TypeScript; Gründer von .NET).

Die Besonderheit dieser Sprache besteht darin, dass sie zusätzlich zu den Funktionen von ES auch viele neue Funktionen enthält, die nicht im Rahmen des Standards liegen. Daher können viele Browser die TypeScript-Syntax nicht direkt unterstützen und müssen kompiliert (in JS kompiliert) werden, bevor sie vom Browser korrekt ausgeführt werden können.

JavaScript-Frameworks

• jQuery: Ein bekanntes JavaScript-Framework. Sein Vorteil liegt in der Vereinfachung von DOM-Operationen. Sein Nachteil ist jedoch, dass DOM-Operationen zu häufig sind und sich dadurch die Leistung des Front-Ends auswirken: Aus Sicht des Front-Ends wird es nur aus Kompatibilitätsgründen mit IE6, 7 und 8 verwendet:
• Angular: Ein von Google erworbenes Frontend-Framework, das von einer Gruppe Java-Programmierer entwickelt wurde. Zu seinen Funktionen gehört die Verlagerung des Backend-MVC-Modells ins Frontend und die Hinzufügung des Konzepts der modularen Entwicklung. Es arbeitet mit Microsoft zusammen und verwendet die TypeScript-Syntax für die Entwicklung. Es ist benutzerfreundlich für Backend-Programmierer, aber nicht so benutzerfreundlich für Frontend-Programmierer. Sein größter Nachteil ist die unsinnige Versionsiteration (z. B. 1. Generation -> 2. Generation, im Grunde zwei verschiedene Dinge bis auf den Namen; zum Zeitpunkt der Veröffentlichung dieses Blogs war Angular 6 bereits veröffentlicht).
• React: Ein von Facebook entwickeltes Hochleistungs-JS-Frontend-Framework: Seine Besonderheit besteht darin, dass es ein neues Konzept **[Virtual DOM] vorschlägt, um reale DOM-Operationen zu reduzieren, DOM-Operationen im Speicher zu simulieren und die Frontend-Rendering-Effizienz effektiv zu verbessern; sein Nachteil besteht darin, dass es kompliziert zu verwenden ist, da man eine zusätzliche **[JSX]**-Sprache lernen muss;
• Vue: Ein progressives JavaScript-Framework. Als progressiv bezeichnet man die schrittweise Implementierung neuer Funktionen, wie etwa modulare Entwicklung, Routing, Statusverwaltung und andere neue Features. Seine Besonderheit besteht darin, dass es die Vorteile von Angular (Modularität) und React (virtueller DOM) kombiniert;
• Axios: Front-End-Kommunikationsframework; da Vue eine klare Grenze hat, nämlich die Verarbeitung von DOM, verfügt es nicht über Kommunikationsfunktionen. Zu diesem Zeitpunkt ist ein zusätzliches Kommunikationsframework erforderlich, um mit dem Server zu interagieren. Natürlich können Sie auch direkt die von jQuery bereitgestellte AJAX-Kommunikationsfunktion verwenden.

UI-Framework

• Ant-Design: Ein UI-Framework basierend auf React von Alibaba
• ElementUl , iview , ice : produziert von Ele.me, basierend auf Vues Ul-Framework
• Bootstrap: Ein von Twitter eingeführtes Open-Source-Toolkit für die Front-End-Entwicklung.
• AmazeUl: auch bekannt als „Girl UI“, ein HTML5-Cross-Screen-Frontend-Framework

JavaScript-Build-Tools

• Babel: JS-Kompilierungstool, das hauptsächlich für neue ES-Funktionen verwendet wird, die von Browsern nicht unterstützt werden, z. B. das Kompilieren von TypeScript
• WebPack: Modulpaketierer, die Hauptfunktion besteht darin, nacheinander zu verpacken, zu komprimieren, zusammenzuführen und zu laden.

Drei-Terminal-Vereinigung

Hybrid App

Der Hauptzweck besteht darin, drei Endgeräte (PC, Android: .apk, iOS: ipa) zu vereinheitlichen und die zugrundeliegende Hardware des Geräts (wie Sensoren, GPS, Kameras usw.) aufrufen zu können. Es gibt zwei Hauptverpackungsmethoden:

• Cloud-Verpackung: HBuild -> HBuildX, produziert von DCloud; API Cloud
• Lokale Verpackung: Cordova (früher PhoneGap)

WeChat Mini-Programm

Weitere Einzelheiten finden Sie auf der offiziellen WeChat-Website. Hier ist ein Framework, das die Entwicklung der WeChat-Applet-Benutzeroberfläche erleichtert: WeUl

Backend-Technologie

Um die Entwicklung zu erleichtern, muss das Front-End-Personal auch bestimmte Back-End-Technologien beherrschen, aber unser Java-Back-End-Personal weiß, dass das Back-End-Wissenssystem extrem umfangreich und komplex ist. Um dem Front-End-Personal die Entwicklung von Back-End-Anwendungen zu erleichtern, sind Technologien wie NodeJS entstanden.

Der Autor von NodeJS hat angekündigt, dass er NodeJS aufgeben wird (die schlechte Architektur und die umständlichen Node_Module haben den Autor möglicherweise unzufrieden gemacht) und mit der Entwicklung von Deno, einer neuen Architektur, begonnen hat.

Da es sich um eine Backend-Technologie handelt, sind auf jeden Fall ein Framework und Projektmanagement-Tools erforderlich. Das NodeJS-Framework und die Projektmanagement-Tools sind wie folgt:

• Express: NodeJS-Framework
• Koa: Express vereinfacht
• NPM: Umfassendes Projektmanagement-Tool, ähnlich wie Maven
• YARN: Eine Alternative zu NPM, ähnlich der Beziehung zwischen Maven und Gradle

Mainstream-Frontend-Frameworks

Vue.js

iView

iview ist eine leistungsstarke Vue-basierte UI-Bibliothek mit vielen praktischen Basiskomponenten, die umfangreicher sind als Elementui-Komponenten. Sie dient hauptsächlich den Mid- und Back-End-Produkten von PC-Schnittstellen. Verwenden Sie das auf npm + webpack + babel-Entwicklung basierende Einzeldatei-Vue-Komponentenentwicklungsmodell, unterstützen Sie die hochwertige, funktionsreiche und benutzerfreundliche API von ES2015 und nutzen Sie den Speicherplatz frei und flexibel.

• Offizielle Website-Adresse.
• Github
• iview-admin

Hinweis: Es handelt sich um ein Mainstream-Frontend-Framework und kann bei der Auswahl berücksichtigt werden. Sein Hauptmerkmal ist, dass es mehr mobile Endgeräte unterstützt.

ElementUl

Element ist eine Vue Ul-Komponentenbibliothek, die von Ele.mes Open Source-Frontend verwaltet wird. Sie verfügt über einen vollständigen Komponentensatz, der im Wesentlichen alle für das Backend erforderlichen Komponenten abdeckt. Die Dokumentation ist ausführlich und die Beispiele umfangreich. Es wird hauptsächlich zur Entwicklung von PC-Seiten verwendet und ist eine hochwertige Vue Ul-Komponentenbibliothek.

Hinweis: Es handelt sich um ein Mainstream-Frontend-Framework und kann bei der Auswahl berücksichtigt werden. Sein Hauptmerkmal ist, dass es mehr Desktop-Terminals unterstützt.

EIS

Feibing ist die Mid- und Back-End-Anwendungslösung des Alibaba-Teams, die auf React/Angular/Vue basiert. Innerhalb von Alibaba wird sie in mehr als 270 Projekten aus fast allen BUs verwendet. Feibing umfasst eine vollständige Verknüpfung vom Entwurfs- zum Entwicklungsende und hilft Benutzern so, schnell ihre eigenen Mid- und Back-End-Anwendungen zu erstellen.

Hinweis: Die Hauptkomponenten basieren immer noch auf React

VantUl

Vant Ul ist eine Vue-Komponentenbibliothek, die vom Front-End-Team von Youzan basierend auf den einheitlichen Spezifikationen von Youzan implementiert wird und einen vollständigen Satz von Ul-Basiskomponenten und Geschäftskomponenten bereitstellt. Mit Vant können Sie schnell Seiten mit einem einheitlichen Stil erstellen und die Entwicklungseffizienz verbessern.

Ut

at-ui ist eine auf Vue 2.x basierende Front-End-UI-Komponentenbibliothek, die hauptsächlich für die schnelle Entwicklung von PC-Website-Produkten verwendet wird. Es bietet eine Reihe von npm + webpack + babel Front-End-Entwicklungs-Workflows mit unabhängigen CSS-Stilen und kann einen einheitlichen UI-Stil beibehalten, selbst wenn unterschiedliche Frameworks verwendet werden.

WürfelUl

cube-ui ist eine anspruchsvolle mobile Komponentenbibliothek, die vom Didi-Team auf Basis von Vue.js entwickelt wurde. Unterstützt die On-Demand-Einführung und Nachkompilierung, leicht und flexibel: starke Skalierbarkeit, kann problemlos eine sekundäre Entwicklung basierend auf vorhandenen Komponenten erreichen.

Warten Sie auf die Benutzeroberfläche …

Front-End-Entwicklungsverlauf

Die vom Backend dominierte MVC-Ära

• Initiieren Sie eine Anfrage an den Front-Controller ( DispatcherServlet )
• Der Front-End-Controller fordert HandlerMapping an, um Handler zu finden, der basierend auf xml Konfiguration und den Anmerkungen gefunden werden kann.
• Der Handler-Mapper HandlerMapping gibt Handler an den Front-Controller zurück
• Der Frontcontroller ruft den Prozessoradapter auf, um Handler auszuführen
• Prozessoradapter zur Ausführung Handler
• Die Ausführung Handler wird abgeschlossen und ModelAndview wird an den Adapter zurückgegeben.
• Der externe Prozessoradapter gibt ModelAndView.ModelAndView an den Front-End-Controller zurück. ModelAndView ist ein zugrunde liegendes Objekt des SprineMvc -Frameworks, einschließlich Model und View
• Der Frontend-Controller fordert den View-Resolver zur View-Auflösung auf und löst den logischen View-Namen in eine reale View (JSP) auf.
• Der View-Resolver gibt View an den Front-Controller zurück
• Der Front-Controller führt das View-Rendering durch, das das request mit Modelldaten füllt (im ModelAndView -Objekt).
• Der Front-Controller reagiert auf den Benutzer

Vorteil

MVC ist ein sehr gutes Kollaborationsmodell, das die Code-Kopplung wirksam reduzieren und Entwicklern ermöglichen kann, zu verstehen, wo der Code aus architektonischer Sicht geschrieben werden sollte. Um die Ansicht reiner zu gestalten, können Sie auch Vorlagen-Engines wie Thymeleaf und Freemarker verwenden, um zu verhindern, dass Java-Code in die Vorlage geschrieben wird, wodurch die Arbeitsteilung zwischen Front-End und Back-End klarer wird.

Mangel

• Die Front-End-Entwicklung hängt stark von der Entwicklungsumgebung ab und weist eine geringe Entwicklungseffizienz auf. Unter dieser Architektur gibt es zwei Arten der Front-End- und Back-End-Zusammenarbeit:
  • Die erste besteht darin, eine DEMO auf das Front-End zu schreiben und dann das Back-End die Vorlage verwenden zu lassen. Der Vorteil ist, dass DEMO lokal entwickelt werden kann, was sehr effizient ist. Der Nachteil ist, dass das Backend die Vorlage anwenden muss, was möglicherweise falsch ist. Nachdem die Anwendung abgeschlossen ist, muss das Frontend sie bestätigen, und die Kosten für Kommunikation und Anpassung sind relativ hoch.
  • Ein weiterer Zusammenarbeitsmodus besteht darin, dass das Front-End für die gesamte browserseitige Entwicklung und die serverseitige Entwicklung von View-Layer-Vorlagen verantwortlich ist. Der Vorteil besteht darin, dass alle U-bezogenen Codes nur vom Front-End geschrieben werden müssen und dem Back-End nicht zu viel Aufmerksamkeit geschenkt werden muss. Der Nachteil besteht darin, dass die Front-End-Entwicklung stark an die Back-End-Umgebung gebunden ist und die Umgebung zu einem wichtigen Faktor wird, der die Effizienz der Front-End-Entwicklung beeinflusst.
• Die Verantwortlichkeiten von Front-End und Back-End sind unklar: Die Template-Engine ist leistungsstark und kann durch die erhaltenen Kontextvariablen dennoch verschiedene Business-Logiken umsetzen.
  

Auf diese Weise ist es so, dass, solange das Front-End noch etwas schwach ist, das Back-End häufig erfordert, dass viel Geschäftscode in die Vorlagenebene geschrieben wird. Es gibt auch einen großen grauen

Die Zone ist der Controller, und Funktionen wie die Seitenweiterleitung sollten sich hauptsächlich um das Front-End kümmern, werden jedoch vom Back-End implementiert.

Der Controller selbst ist häufig mit dem Modell verknüpft, und der Geschäftscode, der den Leuten die Zähne zusammenbeißt, wird in der Controller-Ebene angezeigt. Diese Probleme können nicht ausschließlich auf die Qualität des Programmierers zurückgeführt werden, sonst würde JSP ausreichen.

• Einschränkungen der Front-End-Leistung: Wenn die Leistungsoptimierung nur am Front-End durchgeführt wird, ist der Platz sehr begrenzt, sodass wir häufig eine Back-End-Kooperation benötigen. Aufgrund der Einschränkungen des Back-End-Frameworks ist es für uns jedoch schwierig, technische Lösungen wie **【Comet】, 【BigPipe】** zur Leistungsoptimierung zu verwenden.

Die SPA-Ära mit AJAX

Bereits 2005 wurde AJAX (Asynchronous JavaScript And XML) offiziell vorgeschlagen und CDN als statischer Ressourcenspeicher verwendet, was zur Rückkehr von JavaScript führte.

(Zuvor wurde JS verwendet, um Anzeigen für Hundehautpflaster auf Webseiten zu veröffentlichen) Die SPA-Ära (Single Page Application).

Vorteil

In diesem Modus ist die Arbeitsteilung zwischen Front-End und Back-End sehr klar und der wichtigste Kooperationspunkt zwischen Front-End und Back-End ist die AJAX-Schnittstelle. Es sieht so wunderbar aus, aber rückblickend unterscheidet es sich nicht sehr von der JSP-Ära. Die Komplexität hat sich vom JSP auf dem Server zum JavaScript im Browser verlagert, was die Browserseite sehr komplex macht. Ähnlich wie Spring MVC begann in dieser Ära eine Schichtenarchitektur für Browser aufzutauchen:

Mangel

• Einigkeit über Front-End- und Back-End-Schnittstellen: Wenn die Back-End-Schnittstelle ein Chaos ist und das Back-End-Geschäftsmodell nicht stabil genug ist, wird die Front-End-Entwicklung schmerzhaft: Viele Teams haben ähnliche Versuche unternommen und dabei Schnittstellenregeln, Schnittstellenplattformen usw. verwendet. Mit den gemeinsam mit dem Backend hinterlegten Schnittstellenregeln können diese zudem zur Simulation von Daten genutzt werden, sodass nach Einigung auf die Schnittstelle eine effiziente parallele Entwicklung von Front-End und Back-End möglich ist.
• Komplexitätskontrolle der Front-End-Entwicklung: SPA-Anwendungen sind meist funktional und interaktiv und es ist normal, dass der JavaScript-Code 100.000 Zeilen überschreitet. Die Organisation einer großen Menge an JS-Code und seine Bindung mit der Ansichtsebene sind keine leichten Aufgaben. Die Ära der MV* dominierte das Frontend

Der MV*-Modus ist hier wie folgt:

• MVC (hauptsächlich synchrone Kommunikation): Modell, Ansicht, Controller.
• MVP (hauptsächlich asynchrone Kommunikation): Model, View, Presenter
• MVVM (hauptsächlich asynchrone Kommunikation): Model, View, ViewModel

Um die Komplexität der Front-End-Entwicklung zu reduzieren, sind zahlreiche Front-End-Frameworks entstanden, beispielsweise Angular]s , React , Vue.js , Ember]s usw. Das allgemeine Prinzip dieser Frameworks besteht darin, zunächst Schichten nach Typ anzuordnen, beispielsweise Templates , ontrollers , Models , und diese dann innerhalb der Schichten aufzuteilen, wie unten gezeigt:

Vorteil

• Die Verantwortlichkeiten von Front-End und Back-End sind sehr klar : Das Front-End arbeitet auf der Browserseite und das Back-End arbeitet auf der Serverseite. Durch eine klare Arbeitsteilung ist eine parallele Entwicklung möglich, Testdaten lassen sich problemlos simulieren und das Frontend kann lokal entwickelt werden. Das Backend kann sich auf die Verarbeitung der Geschäftslogik und die Ausgabe von RESTful und anderen Schnittstellen konzentrieren.
• Die Komplexität der Front-End-Entwicklung ist kontrollierbar: Der Front-End-Code ist schwer, aber eine sinnvolle Schichtung ermöglicht es dem Front-End-Code, seine jeweiligen Funktionen auszuführen. Das ist ziemlich interessant. Sogar etwas so Einfaches wie die Auswahl von Vorlagenfunktionen erfordert viel Überlegung. Es ist nicht so, dass mehr Leistung besser ist. Was man einschränken sollte, welche Freiheiten man lassen sollte, wie der Code organisiert werden sollte – all diese Konzepte zu erklären würde ein ganzes Buch erfordern.
• Relativ unabhängige Bereitstellung : kann das Produkterlebnis schnell verbessern

Mangel

• Der Code kann nicht wiederverwendet werden. Beispielsweise muss das Backend noch verschiedene Prüfungen der Daten durchführen und die Überprüfungslogik kann den browserseitigen Code nicht wiederverwenden. Bei Wiederverwendung kann die Back-End-Datenüberprüfung relativ vereinfacht werden.
• Vollständig asynchron, nicht gut für SEO. Oftmals ist es auch erforderlich, dass der Server eine Downgrade-Lösung für das synchrone Rendering implementiert.
• Insbesondere in mobilen Internetumgebungen ist die Leistung nicht optimal.
• SPA kann nicht alle Anforderungen erfüllen und es gibt immer noch eine große Anzahl mehrseitiger Anwendungen. Das URL-Design erfordert die Zusammenarbeit mit dem Backend und kann nicht vollständig vom Frontend gesteuert werden.

Die Full-Stack-Ära mit NodeJS

Das MV*-Modell, das sich auf den vorderen Teil konzentriert, löst viele Probleme, weist aber, wie oben erwähnt, immer noch viele Mängel auf. Mit dem Aufkommen von NodeJS kann JavaScript auf Servern ausgeführt werden. Dies bedeutet, dass es ein neues Modell für Forschung und Entwicklung gibt:

In diesem F&E-Modell sind die Verantwortlichkeiten von Front-End und Back-End sehr klar. Für das Frontend haben die beiden UI-Ebenen ihre eigenen Aufgaben:

• Front-end Ul layer verarbeitet die Präsentationslogik der Browserschicht. Die Stile werden über CSS gerendert, interaktive Funktionen werden über JavaScript hinzugefügt und je nach Anwendungsszenario kann auch die HTML-Generierung auf dieser Ebene erfolgen.
• Back-end Ul layer kümmert sich um Routing, Vorlagen, Datenerfassung, Cookies usw. Durch Routing kann das Front-End das URL-Design schließlich unabhängig steuern, sodass das Front-End es frei anpassen kann, unabhängig davon, ob es sich um eine einseitige oder eine mehrseitige Anwendung handelt. Das Backend kann sich endlich von seinem starken Fokus auf die Präsentation lösen und sich stattdessen auf die Entwicklung der Business-Logik-Schicht konzentrieren.

Durch Node ist die Webserverschicht auch JavaScript-Code, was bedeutet, dass einige Codes vorher und nachher wiederverwendet werden können. Szenarien, die SEO erfordern, können synchron auf der Serverseite gerendert werden, und Leistungsprobleme, die durch zu viele asynchrone Anforderungen verursacht werden, können auch über die Serverseite gemildert werden. Die Mängel des Vorgängermodells können durch dieses Modell nahezu perfekt behoben werden.

Im Vergleich zum JSP-Modell scheint das Full-Stack-Modell eine Regression zu sein, und es ist tatsächlich eine Regression zum ursprünglichen Entwicklungsmodell, aber es ist eine Spiralregression.

Das auf NodeJS basierende Full-Stack-Modell steht noch vor vielen Herausforderungen:

• Das Frontend muss über ein tieferes Verständnis der serverseitigen Programmierung verfügen. Beispielsweise die Beherrschung von Netzwerkkenntnissen wie TCP/IP.
• Effiziente Kommunikation zwischen NodeJS-Schicht und Java-Schicht. Im NodeJS-Modus befindet sich alles auf der Serverseite, die RESTful-HTTP-Kommunikation ist möglicherweise nicht effizient und die Kommunikation über SOAP und andere Methoden ist effizienter. Bevor Sie fortfahren, muss alles überprüft werden.
• Ein fundiertes Verständnis von Bereitstellung, Betrieb und Wartung erfordert mehr Wissen und praktische Erfahrung.
• Wie bewältigt man eine große Zahl historischer Probleme? Dies dürfte das größte Hindernis sein.

Zusammenfassen

Dieser Artikel endet hier. Ich hoffe, er kann Ihnen helfen. Ich hoffe auch, dass Sie mehr Inhalten auf 123WORDPRESS.COM mehr Aufmerksamkeit schenken können!