it-swarm.com.de

Verantwortung für die Anordnung der Elemente - Frontend oder Backend?

In unserem Unternehmen hatten wir kürzlich eine Diskussion darüber, welcher Teil einer Anwendung für die (Neu-) Anordnung der Elemente einer Liste verantwortlich ist.

Die Liste ist eine visuelle Darstellung der Schritte, die in der Produktion ausgeführt werden müssen. Das Backend bietet es in der "normalen" Reihenfolge (1., 2., 3., 4.). Im Frontend ganz oben sollte das 4. Element sein, unten ist das 3., unten das 2. ... Da es sich um eine Website handelt, muss das Frontend von oben nach unten gerendert werden, es ist die falsche Reihenfolge für die Website. Er braucht die Elemente 4., 3., 2., 1., um es richtig zu machen.

Dies sind maximal 10 Elemente, die jedes Mal angezeigt werden. Es werden also keine Seitenwechsel oder Filter benötigt.

Grundsätzlich benötigt das Frontend die Elemente in umgekehrter Reihenfolge, von denen das Backend sie zurückgibt. Mein Kollege, ein Frontend-Entwickler, sagt, es sei die Aufgabe des Backends. Meiner Meinung nach (als Backend-Entwickler) ist es Teil des Frontends.

Seine Punkte:

  • das Frontend ist "unantastbar". Wenn sich die Präsentation ändert, müssen wir im Frontend nichts ändern.
  • das Frontend sagt, was es braucht und das Backend muss sich anpassen.
  • das Frontend ist dumm - es sollte keine Logik enthalten.

Meine Punkte:

  • es ist eine Frage der Repräsentation. Das Backend sollte sich überhaupt keine Sorgen machen müssen. Es ist ihm egal (und er weiß), in welcher Reihenfolge er die Gegenstände braucht.
  • falsche Verantwortung. Ich möchte nicht an meinem Automotor arbeiten, wenn ich Reifen wechseln möchte. Wenn sich also die Benutzeroberfläche ändert (d. H. Eine andere Anordnung), sollten die Änderungen in der Benutzeroberfläche erfolgen.
  • Ich möchte nicht spezifisch für eine Benutzeroberfläche sein. If Wir fügen ein anderes Frontend hinzu (was wir wahrscheinlich nicht tun werden) und es wird die Liste nicht auf die gleiche Weise anzeigen. Müssen wir dafür eine andere Methode bereitstellen?

Ich denke, Sie verstehen unsere Ansichten. Es ist keine Frage der Implementierung, da es sich wahrscheinlich um eine Codezeile handelt. Es ist eine architektonische Frage, da wir einen neuen Teil des Systems planen. Vielleicht brauchen wir nur eine weitere Schicht dazwischen. Aber auf welcher Seite, Frontend oder Backend?

Letzte Änderung: Vielen Dank für Ihre Antworten, diese waren viel detaillierter als ich erwartet hatte. Für diejenigen, die interessiert sind, ist hier die Art und Weise, wie wir es gemacht haben. Obwohl die Mehrheit empfohlen hat, das Backend einzufügen, werden wir die Logik in das Frontend einfügen. Warum? Hauptsächlich, weil ich es zu locker beschrieben habe und die Antworten auf Fakten und Anforderungen beruhten, die ich zu spät beschrieben habe. Per Definition ist diese Liste von max. 10 Elemente sind in der richtigen Reihenfolge angeordnet. Und da das Frontend es in einer anderen Reihenfolge benötigt, was nur darauf zurückzuführen ist, dass es einfacher ist, es auf diese Weise im Web zu rendern, ist es eine reine Präsentationssache. Versteh mich nicht falsch, alle Antworten waren sehr nützlich und wir haben viele Informationen daraus entnommen. Ich denke, Overengineering war das Schlüsselwort, das wir brauchten, um zu erkennen, dass wir niemals Filter, Paging oder irgendetwas anderes in dieser API benötigen werden. Aber zum Teufel, wir haben viel mehr gelernt als wir erwartet hatten!

35
Sn0bli

Jede anständige Back-End-API sollte Parameter erhalten, die eine Anpassung oder Filterung der Ergebnisse ermöglichen, die sie an den Client zurückgibt. Für etwas, das eine Liste zurückgibt, ist es normalerweise üblich, Folgendes anzugeben:

  • bestellparameter (ASC oder DESC) basierend auf einigen Feldkriterien;
  • parameter für die Paginierung;
  • parameter für die Suchabfrage (d. h. Filtern der Liste, um nur eine Teilmenge von Datensätzen anzufordern).

Es ist nicht immer eine Regel, aber oft finden Sie alle diese drei Elemente zusammen.

Wenn eine Back-End-API nur eine Liste der Ergebnisse zurückgibt und dann "das Problem des Front-End ist, was es damit macht", ist dies meistens eine schlechte Idee. Dies führt dazu, dass die Benutzeroberfläche komplizierter wird und etwas tut, das das Back-End sehr einfach und ohne Beeinträchtigung der Leistung ausführen kann.

Lassen Sie uns die Diskussion für eine Sekunde wechseln und über den Anwendungsfall nachdenken, bei dem die Liste in der Benutzeroberfläche paginiert wird. Werden Sie das Front-End zwingen, die gesamte Liste abzurufen, im Speicher zu behalten und die Paginierung auf der Clientseite durchzuführen? Was ist, wenn jemand beschließt, die vollständige Liste jedes Mal anzufordern, wenn der Benutzer auf die nächste Seite klickt?

Was ich sage ist, dass es ein Kompromiss ist. Einige Dinge müssen im Backend erledigt werden, andere im Frontend. Es ist nicht "alles im Backend" oder "alles im Frontend". Besprechen Sie es zwischen Ihnen und vereinbaren Sie, was die API zurückgeben und welche Parameter sie erhalten soll. Grundsätzlich, um eine API zu erstellen, die flexibel ist, nicht eine, die starr ist.

Und wenn es Ihnen nichts ausmacht, dass ich ganz ehrlich bin, ist dies keine architektonische Frage. Architektur ist wichtig . Die Reihenfolge der Elemente auf dem Bildschirm ist nicht wichtig, daher nicht die Architektur.

81
Bogdan

Thin Clients

Wenn Ihr Kollege sagt, der Kunde sei dumm, meint er die Idee eines dünnen Kunden. Wenn Sie Ihre API beschreibend und nicht nur mit einfachen CRUD-Operationen (Erstellen, Lesen, Aktualisieren, Löschen) entwerfen, ist es einfach, einen dummen Client zu schreiben, der einfach die API verbraucht und nur das Ergebnis anzeigt. Dieser Ansatz stellt sicher, dass sowohl das Frontend als auch das Backend relativ einfach bleiben.

Delegieren an den Client

Wenn Sie jetzt eine größere Anwendung entwerfen, deren Anwendungsfälle komplizierter sind, möchten Sie möglicherweise die Idee nutzen, CPU-intensive Arbeit an den Client zu delegieren. Wenn Ihr Server von vielen Clients verwendet wird, ist es sinnvoll, einzelne Berechnungen auf den Client zu verschieben, um das System zu beschleunigen.

Big Data

Das Problem bei der Delegierung an den Client besteht darin, dass in den meisten Anwendungsdesigns Ihre Datenschicht eine der schwierigsten ist, um die Leistung zu optimieren. Es macht keinen Sinn, eine große Liste von Daten abzufragen, die an den Client gesendet und dort angezeigt werden, um sie dann zu filtern. Bei einer bestimmten Datenmenge ist es besser, die hochoptimierten Datenbankalgorithmen zu verwenden, um Ihre Daten zu ordnen, zu filtern und zu paginieren. Sie sichern auch die Bandbreite.

Fazit

Tun Sie, was immer es am einfachsten hält und Ihre Leistungsanforderungen erfüllt.

Adressierung der Bearbeitung

Wenn es nur eine richtige Reihenfolge gibt und die Daten zur besseren Visualisierung nicht neu angeordnet werden müssen, ist es Aufgabe des Backends, die Bestellung durchzuführen.

3
NtFreX

Ihre Bearbeitung fügt einen Kontext hinzu, der für IMO wichtig ist. Dies ist keine abstrakte Datenquelle, die in beliebiger Reihenfolge angezeigt werden kann oder nach verschiedenen Attributen sortiert wird. Dies ist ein physikalischer Prozess mit einer bestimmten Reihenfolge.

Dies bedeutet, dass das Backend, das am besten über den Prozess Bescheid wissen sollte, die Informationen in der richtigen Reihenfolge bereitstellt. Das Frontend sollte sich keine Sorgen machen müssen, dass das Backend die Prozessschritte in umgekehrter oder zufälliger Reihenfolge ausführt.

Das Frontend muss die Schritte in der eingegangenen Bestellung anzeigen. Was es dazu tut (kein Wortspiel beabsichtigt), liegt an ihm.

3
jmoreno

Sie und Ihr Kollege haben beide im Wesentlichen Recht mit "was Sie denken". Was Sie vermisst haben, ist eine dritte Kernkomponente der modernen Programmierung, das Modell. In der MVC-Architektur (Model-View-Controller) besteht das Modell aus einer Reihe von Datendateien, Datenbanktabellen oder anderen "Daten", die die Felder, ihre Anordnung, die Reihenfolge der Auswahlwerte usw. Beschreiben .

Die Ansicht ist das, was Sie als "Front-End" bezeichnet haben, und sie sollte in der Tat ein Minimum an Logik enthalten, wie Ihr Kollege behauptet. Tatsächlich wurden Verbindungen zu einem Mainframe ursprünglich über ein "dummes Terminal" hergestellt. Sie wurden so genannt, weil sie praktisch keine Logik hatten und nur zeigten, was der Server ohne Änderung anzeigte. Hier können jedoch Ausnahmen gemacht werden. Vielleicht hat eine Ansicht die Option "Standard" oben in der Liste oder etwas anderes, aber das sollte von Fall zu Fall sein.

Der Controller ist das, was Sie als "Back-End" bezeichnet haben, und er sollte für die Validierung der erforderlichen Felder, die Durchsetzung von Geschäftsregeln usw. verantwortlich sein. Er sollte auch nicht speziell die Reihenfolge der Auswahlwerte vorgeben. Es sollte das Modell konsultieren und alles zurückgeben, was das Modell definiert. In diesem Fall ist Ihr Controller falsch, wenn Sie das Modell in "umgekehrter" Reihenfolge zurückgeben.

Durch Hinzufügen einer dritten Komponente können Systemadministratoren die Auswahlwerte ändern, ohne die Geschäftsregeln beeinflussen oder die Front-End-Logik aktualisieren zu müssen. Tatsächlich muss das SA in dieser Situation nicht einmal ein Programmierer sein, da die Dateien, die geändert werden müssen, normalerweise über eine Admin-App in irgendeiner Form verfügbar gemacht werden. Selbst wenn Sie dies nicht tun Ich glaube nicht, dass Sie diese Art von Flexibilität jetzt brauchen, es ist normalerweise ein minimaler Aufwand, etwas jetzt zu codieren, damit Sie später die Option haben.

Letztendlich würde Ihr System von der Entwicklung eines Modells profitieren, das sowohl das Front-End als auch das Back-End nutzen können, um eine konsistente Erfahrung zu bieten. Weder die Front-End- noch die Back-End-Entwickler sollten sich über die Reihenfolge der Auswahlwerte streiten, da es sich um eine Datendatei handeln sollte, die möglicherweise geändert werden kann, um das Systemverhalten zu beeinflussen, ohne den Code zu ändern. Es wird jetzt mehr Arbeit für Sie sein , um sicher zu sein, aber am Ende wird jeder produktiver sein, wenn ein effektives Modell vorhanden ist.


Quelle: Fast 15 Jahre Erfahrung (Stand 2019) mit salesforce.com als technischer Support, Berater, Administrator und Entwickler.

2
phyrfox