Ich habe mich gefragt, ob jemand die Unterschiede zwischen Frontend, Backend und Middleware ("Middle-End"?) Kurz und bündig vergleichen kann.
Gibt es Fälle, in denen sie sich überschneiden? Gibt es Fälle, in denen sie sich überlappen MÜSSEN und Frontend / Backend nicht getrennt werden können? Welches Ende ist in Bezug auf Engpässe mit welcher Art von Engpässen verbunden?
Antworten:
Hier ist eine Aufschlüsselung:
Front-End-Schicht -> Benutzeroberflächenebene, die normalerweise aus einer Mischung aus HTML, Javascript, CSS, Flash und verschiedenen serverseitigen Codes wie ASP.Net, klassischem ASP, PHP usw. besteht. Stellen Sie sich dies als dem Benutzer am nächsten stehend vor in Bezug auf Code.
Middleware, Middle-Tier -> One-Tier-Back, allgemein als "Sanitär" -Teil eines Systems bezeichnet. Java und C # sind gebräuchliche Sprachen zum Schreiben dieses Teils, die als Bindeglied zwischen der Benutzeroberfläche und den Daten angesehen werden können und möglicherweise Webservices oder WCF-Komponenten oder andere SOA-Komponenten sein können.
Back-End-Schicht -> Datenbanken und andere Datenspeicher befinden sich im Allgemeinen auf dieser Ebene. Oracle, MS-SQL, MySQL, SAP und verschiedene Standard-Software-Teile kommen für diese Software in den Sinn, die die endgültige Verarbeitung der Daten darstellt.
Zwischen diesen kann eine Überlappung bestehen, da alles wie in einer ASP.Net-Website, die die integrierte AJAX-Funktionalität verwendet, die Javascript generiert, in eine Ebene eingefügt werden kann, während der Code dahinter möglicherweise Datenbankbefehle enthält, sodass der Code dahinter sowohl die Mitte als auch die Rückseite enthält -end Ebenen. Alternativ könnte man VBScript verwenden, um mit ADO-Objekten als alle Ebenen zu fungieren und alle drei Ebenen zu einer zusammenzuführen.
In einigen Fällen kann die Verwendung von Middleware und entweder Front- oder Back-End kombiniert werden.
Engpässe haben im Allgemeinen einige unterschiedliche Ebenen:
1) Datenbank- oder Back-End-Verarbeitung -> Dies kann von der Personalabrechnung oder dem Verkauf bis zu anderen Aufgaben abweichen, bei denen der Durchsatz in die Datenbank ins Stocken gerät.
2) Middleware-Engpässe -> Hier könnte ein Webdienst die Kapazität erreichen, aber das Front- und Back-End verfügen über Bandbreite, um mehr Verkehr zu verarbeiten. Alternativ kann es einen Server geben, der Teil eines Systems ist, das nicht ganz der UI-Teil ist, oder die Rohdaten, die einen Engpass bei der Verwendung von Biztalk oder MSMQ darstellen können.
3) Front-End-Engpässe -> Dies kann zu Problemen auf der Client- oder Serverseite führen. Wenn Sie beispielsweise einen Low-End-PC mit einer Webseite geladen haben, auf der viele Daten heruntergeladen wurden, befindet sich der Client möglicherweise dort, wo der Engpass liegt. In ähnlicher Weise könnte der Server Anfragen in die Warteschlange stellen, wenn er mit Anfragen wie Amazon.com oder anderen Websites mit hohem Datenaufkommen überhäuft wird.
Einiges davon unterliegt der Interpretation, daher ist es keineswegs perfekt und YMMV.
BEARBEITEN: Zu berücksichtigen ist, dass einige Systeme mehrere Front-Ends oder Back-Ends haben können. Ein Content-Management-System bietet beispielsweise Website-Besuchern wahrscheinlich die Möglichkeit, den Front-End-Inhalt anzuzeigen. Wie können Content-Editoren die Daten auf der Website ändern? Die Möglichkeit, diese Daten abzurufen, kann als Front-End angesehen werden, da es sich um eine UI-Komponente handelt, oder als Back-End, da sie von internen Benutzern und nicht von der allgemeinen Öffentlichkeit verwendet werden, die die Site betrachtet. Daher gibt es hier etwas für den Kontext zu sagen.
Im Allgemeinen wird die Präsentationsschicht einer Anwendung als Front-End , die Persistenzschicht (normalerweise Datenbank) als Back-End und alles dazwischen als mittlere Ebene bezeichnet . Diese Ideen werden häufig als dreistufige Architektur bezeichnet. Mit ihnen können Sie Ihre Anwendung in leichter verständliche (und testbare!) Abschnitte unterteilen. Sie können Code niedrigerer Ebene auch einfacher in höheren Ebenen wiederverwenden.
Welcher Code zu welcher Ebene gehört, ist etwas subjektiv. Grafikdesigner neigen dazu, alles, was nicht Präsentation ist, als Backend zu betrachten, Datenbankleute denken an alles vor der Datenbank als Frontend und so weiter.
Es müssen jedoch nicht alle Anwendungen auf diese Weise getrennt werden. Es ist sicherlich mehr Arbeit, drei separate Unterprojekte zu haben, als nur index.php zu öffnen und loszulegen. Abhängig davon, (1) wie lange Sie die App warten müssen (2) wie komplex die App voraussichtlich sein wird, möchten Sie möglicherweise auf die Komplexität verzichten.
Es gibt tatsächlich 3 Fragen in Ihrer Frage:
Was JB King beschrieben hat, ist richtig, aber es ist eine bestimmte, einfache Version, bei der er tatsächlich Front, Mitte und Bacn einer MVC-Ebene zugeordnet hat. Er ordnete M nach hinten, V nach vorne und C nach Mitte zu.
Für viele Menschen ist es in Ordnung, da sie aus der hässlichen Welt stammen, in der nicht einmal MVC angewendet wurde, und Sie direkte DB-Aufrufe in einer Ansicht haben könnten.
In realen, komplexen Webanwendungen haben Sie jedoch zwei oder drei verschiedene Ebenen, die als Vorder-, Mittel- und Rückseite bezeichnet werden. Jedem von ihnen kann eine Datenbank und ein Controller zugeordnet sein.
Das Frontend ist für den Endbenutzer sichtbar. Es sollte nicht mit dem Front-Office verwechselt werden, bei dem es sich um die Benutzeroberfläche für Parameter und die Verwaltung der Front handelt. Das Front-End ist normalerweise eine Art CMS oder E-Commerce-Plattform (Magento usw.)
Das mittlere Ende ist nicht obligatorisch und dort befindet sich die Geschäftslogik. Es basiert auf einem PIM, einem MDM-Tool oder einer benutzerdefinierten Datenbank, in der Sie Ihre Produkte oder Artikel (für CMS) anreichern. Hier können Sie auch Geschäftsfunktionen codieren, die von verschiedenen Frontends gemeinsam genutzt werden müssen (z. B. zwischen dem PC-Frontend und der API-basierten mobilen Anwendung). Manchmal ist ein ESB oder ein Tool wie ActiveMQ Ihr mittleres Ende
Das Back-End ist eine dritte Schicht, die Ihre Quellendatenbank oder Ihr ERP umgibt. Möglicherweise ist es nur die API, die in Ihr ERP schreibt und von diesem liest. Es kann Ihre Lieferanten-DB sein, wenn Sie E-Commerce betreiben. Tatsächlich hängt es wirklich von Webprojekten ab, aber es ist immer ein zentrales Repository. Der Zugriff erfolgt entweder über einen DB-Aufruf, über eine API, eine Ruhezustandsschicht oder eine Back-End-Anwendung mit vollem Funktionsumfang
Diese Beschreibung bedeutet, dass die Beantwortung der anderen beiden Fragen in diesem Thread nicht möglich ist, da Engpässe wirklich davon abhängen, was Ihre drei Enden enthalten: Was JB King geschrieben hat, gilt weiterhin für einfache MVC-Architekturen
Zu dem Zeitpunkt, als die Frage gestellt wurde (vor 5 Jahren), war das MVC-Muster möglicherweise noch nicht so weit verbreitet. Es gibt absolut keinen Grund, warum das MVC-Muster nicht befolgt und eine Ansicht an DB-Aufrufe gebunden wird. Wenn Sie die Frage lesen "Gibt es Fälle, in denen sie sich überschneiden MÜSSEN und Frontend / Backend nicht getrennt werden können?" im weiteren Sinne mit 3 verschiedenen Komponenten gibt es dann Zeiten, in denen die 3-Schichten-Architektur natürlich nutzlos ist. Stellen Sie sich ein einfaches persönliches Blog vor, Sie müssen keine externen Daten abrufen oder RabbitMQ-Warteschlangen abfragen.
Hier ist ein Beispiel aus der Praxis, das Front / Mid / Back End zeigt.
Es ist möglich, dass sich Frontend und Backend überschneiden. Dies führt normalerweise zu langfristigen Problemen bei der Anwendungswartung und Skalierbarkeit. Ziemlich häufig in Legacy-Anwendungen.
Die meisten modernen Technologie-Stacks ermutigen Entwickler zu einer strikten Trennung. Auf dem Bild sehen Sie beispielsweise, dass das Backend des ersten Systems über einen Rest-Webdienst verfügt, der eine klare Trennlinie darstellt.
Die meisten großen Engpässe werden durch die Datenbank / das Netzwerk verursacht. Datenbanken befinden sich im Backend. Bei Netzwerkproblemen wird jede Verbindung über netowrk ausgeführt, sodass jede Verbindung möglicherweise langsam ist. Mit einem guten Anwendungsdesign können diese Probleme weitgehend vermieden werden.
In Bezug auf Netzwerk und Sicherheit ist das Backend bei weitem der sicherste Knoten (sollte es sein).
Der mittlere Teil, normalerweise ein Webserver, ist etwas wild und in vielerlei Hinsicht vom Netzwerk eines Unternehmens abgeschnitten. Der mittlere Knoten wird normalerweise in der DMZ platziert und mit Firewall-Einstellungen vom Netzwerk segmentiert. Der größte Teil der serverseitigen Code-Analyse von Webseiten wird auf dem Middle-End-Webserver ausgeführt.
Um zum Backend zu gelangen, müssen Sie das mittlere Ende durchlaufen, das über sorgfältig ausgearbeitete Regeln verfügt, die den Zugriff auf die auf dem Datenbankserver (Backend) gespeicherten wichtigen Nummern ermöglichen / verbieten.
Frontend bezieht sich auf die Clientseite, während sich Backend auf die Serverseite der Anwendung bezieht. Beide sind für die Webentwicklung von entscheidender Bedeutung, aber ihre Rollen, Verantwortlichkeiten und Umgebungen, in denen sie arbeiten, sind völlig unterschiedlich. Frontend ist im Grunde das, was Benutzer sehen, während Backend ist, wie alles funktioniert