fetch und asynchrone Abläufe: klare Lade- und Fehlerzustände

Eine nachgeladene Liste braucht mehr als einen erfolgreichen fetch-Aufruf. Menschen müssen erkennen, was gerade passiert, ob eine Antwort brauchbar ist und welche Auswahl sie tatsächlich sehen. Besonders bei schnellen Wechseln kann eine ältere Anfrage sonst einen neueren Zustand überschreiben. Dieser Leitfaden entwickelt eine kleine Lernangebotsliste mit klaren Lade-, Fehler- und Abbruchzuständen und zeigt, welche Grenzen dabei auf der Clientseite bleiben.

Die sichtbaren Zustände vor dem Code festlegen

Die Oberfläche bietet zwei Ansichten: alle Angebote und Workshops. Nach der Auswahl beginnt eine Anfrage. Bis zur erfolgreichen Aktualisierung bleibt eine vorhandene Liste sichtbar. Eine gültige leere Antwort wird als leeres Ergebnis dargestellt. Bei einem Fehler wird dagegen nicht behauptet, es gebe keine Angebote. Ein bewusster Abbruch unterscheidet sich wiederum von einem technischen Problem.

Diese Vereinbarung ist Teil der Funktion. Ohne sie entstehen leicht widersprüchliche Rückmeldungen: Ein rot gefärbter Hinweis sagt „fehlgeschlagen“, während die Liste still geleert wurde oder eine alte Erfolgsmeldung stehen bleibt. Beschreiben Sie deshalb für jeden Zustand, welche Daten sichtbar bleiben und welche nächste Handlung möglich ist.

Die acht Sekunden im Beispiel sind eine ausdrücklich gewählte Oberflächenregel für diesen Lernversuch. Sie sind kein allgemeiner Standardwert für gute Schnittstellen. Eine Produktionsanwendung muss Warteverhalten und Wiederholung an ihre tatsächliche Aufgabe anpassen.

Eine kleine zugängliche Grundlage anlegen

Die Ansichtsauswahl besteht aus echten Schaltflächen. Die Statusmeldung besitzt einen dafür vorgesehenen Bereich. Die Liste wird während einer laufenden Anfrage als beschäftigt gekennzeichnet. Dadurch müssen ihre vorhandenen Einträge nicht schon beim Start verschwinden. Der Abbruchknopf ist nur verfügbar, solange eine aktuelle Anfrage bearbeitet wird.

<section id="angebote" aria-labelledby="angebote-titel">
  <h2 id="angebote-titel">Lernangebote</h2>
  <div>
    <button type="button" data-bereich="alle">Alle Angebote</button>
    <button type="button" data-bereich="workshop">Workshops</button>
    <button type="button" id="abbrechen" disabled>Laden abbrechen</button>
  </div>
  <p id="ladestatus" role="status">Wählen Sie eine Ansicht.</p>
  <ul id="angebotsliste" aria-busy="false"></ul>
</section>

Die W3C-Erläuterung zu Statusmeldungen behandelt Änderungen, die assistiven Technologien ohne Fokusverschiebung mitgeteilt werden können. Die gewählten Attribute unterstützen diesen Zweck. Eine DOM-Prüfung ist dennoch kein tatsächlicher Test jeder Screenreader-Konfiguration. Beschreiben Sie den Umfang Ihrer eigenen Prüfung entsprechend.

Nach einer Aktualisierung springt der Fokus im Beispiel nicht ungefragt in die Ergebnisliste. Wer die Ansicht gewählt hat, kann die Oberfläche weiter bedienen. Prüfen Sie für komplexere Anwendungen, ob zusätzliche Orientierung nötig ist, statt bei jeder Antwort pauschal den Fokus zu versetzen.

Den Schnittstellenvertrag vorab beschreiben

Unser Client erwartet eine Antwort mit dem Medientyp application/json und einem Objekt mit dem Feld offers. Dieses Feld enthält eine Liste von Einträgen mit eindeutiger Kennung und Titel. Für die Darstellung werden keine HTML-Fragmente und keine auszuführenden Befehle benötigt. Der Vertrag ist absichtlich klein, damit seine Prüfung nachvollziehbar bleibt.

{
  "offers": [
    { "id": "html-workshop", "title": "HTML-Workshop" },
    { "id": "css-praxis", "title": "CSS-Praxis" }
  ]
}

Die Daten sind erfunden. Für die Verwendung des Clients wird eine passende Schnittstelle unter dem im Code genannten Pfad benötigt. Die später beschriebenen Prüfungen stellen ihre Antworten kontrolliert bereit. Diese Abgrenzung verhindert, dass ein Lehrbeispiel versehentlich als tatsächlich angebotener externer Dienst verstanden wird.

Eine leere offers-Liste ist eine gültige fachliche Antwort. Ein fehlendes Feld oder eine statt des Objekts gelieferte HTML-Anmeldeseite ist etwas anderes. Wenn diese Fälle gleichbehandelt werden, erhalten Menschen einen irreführenden Eindruck vom tatsächlichen Zustand.

fetch und HTTP-Erfolg auseinanderhalten

Die MDN-Anleitung zu fetch erläutert, dass eine HTTP-Antwort mit einem Fehlerstatus nicht automatisch zur Ablehnung des Promise führt. Ein Server kann beispielsweise 404 oder 500 antworten und fetch liefert trotzdem ein Response-Objekt. Der Client muss den Antwortstatus selbst berücksichtigen.

Response.ok zeigt an, ob der Status im Bereich 200 bis 299 liegt. Unsere Anwendung prüft dies vor dem Lesen der fachlichen Daten. Ein positiver Wert beweist allerdings noch nicht, dass die Antwort den erwarteten Inhalt besitzt. Dafür folgen Medientyp- und Strukturprüfung.

Trennen Sie auch eine erfolgreiche Übertragung von einer fachlich erfolgreichen Operation. Ein lesender Abruf kann ein leeres Ergebnis liefern. Eine andere Schnittstelle könnte eine ausdrückliche fachliche Ablehnung beschreiben. Der HTTP-Status ist ein wichtiger Teil des Vertrags, aber nicht seine vollständige Bedeutung.

Der vollständige Client für die Angebotsliste

Das Skript wird nach dem oben gezeigten HTML ausgeführt. Es geht deshalb bewusst von dieser vorhandenen Struktur aus. Die erlaubten Ansichten sind im Programm festgelegt. Eine frei eingegebene URL wird nicht übernommen. Jede laufende Anfrage besitzt ihren eigenen Controller und eine fortlaufende Versionskennung.

const root = document.querySelector('#angebote');
const list = root.querySelector('#angebotsliste');
const status = root.querySelector('#ladestatus');
const cancel = root.querySelector('#abbrechen');
let activeController = null;
let requestVersion = 0;

async function loadOffers(area) {
  if (!['alle', 'workshop'].includes(area)) return;
  activeController?.abort();
  const version = ++requestVersion;
  const controller = new AbortController();
  activeController = controller;
  let timedOut = false;
  const timer = setTimeout(() => {
    timedOut = true;
    controller.abort();
  }, 8000);
  list.setAttribute('aria-busy', 'true');
  cancel.disabled = false;
  status.textContent = 'Ansicht wird geladen. Die bisherige Liste bleibt vorerst bestehen.';

  try {
    const response = await fetch('/api/angebote?bereich=' + area, {
      signal: controller.signal,
      headers: { Accept: 'application/json' }
    });
    if (!response.ok) throw new Error('HTTP ' + response.status);
    const contentType = response.headers.get('content-type')?.split(';')[0].trim().toLowerCase();
    if (contentType !== 'application/json') throw new Error('Unerwartetes Antwortformat');
    const data = await response.json();
    if (!Array.isArray(data?.offers) || data.offers.length > 100
        || data.offers.some(offer => !offer || typeof offer.id !== 'string'
          || !offer.id.trim() || offer.id.length > 64 || typeof offer.title !== 'string'
          || !offer.title.trim() || offer.title.length > 140)
        || new Set(data.offers.map(offer => offer.id)).size !== data.offers.length) {
      throw new Error('Unerwartete Datenstruktur');
    }
    if (version !== requestVersion || controller.signal.aborted) return;
    const items = data.offers.map(offer => {
      const item = document.createElement('li');
      item.textContent = offer.title;
      return item;
    });
    list.replaceChildren(...items);
    status.textContent = items.length
      ? (items.length === 1 ? '1 Angebot geladen.' : items.length + ' Angebote geladen.')
      : 'Für diese Auswahl sind keine Angebote vorhanden.';
  } catch (error) {
    if (version !== requestVersion) return;
    const unchanged = list.children.length
      ? ' Die bisherige Liste bleibt unverändert.'
      : ' Es wurde keine Liste geladen.';
    status.textContent = controller.signal.aborted
      ? (timedOut ? 'Die Anfrage hat zu lange gedauert.' : 'Laden abgebrochen.') + unchanged
      : 'Die Liste konnte nicht aktualisiert werden. Bitte erneut versuchen.' + unchanged;
  } finally {
    clearTimeout(timer);
    if (version === requestVersion) {
      list.setAttribute('aria-busy', 'false');
      cancel.disabled = true;
      activeController = null;
    }
  }
}

root.addEventListener('click', event => {
  if (!(event.target instanceof Element)) return;
  const button = event.target.closest('button[data-bereich]');
  if (button && root.contains(button)) loadOffers(button.dataset.bereich);
});
cancel.addEventListener('click', () => activeController?.abort());
window.addEventListener('pagehide', () => activeController?.abort());

Für eine größere Anwendung kann die Funktion in eine Komponente mit ausdrücklich geregeltem Aufbau und Abbau überführt werden. Dabei bleiben dieselben Zuständigkeiten wichtig: aktuelle Anfrage, sichtbare Daten und Rückmeldung dürfen nicht durch voneinander unabhängige Routinen widersprüchlich verändert werden.

Warum eine ältere Antwort gefährlich sein kann

Stellen Sie sich zwei aufeinanderfolgende Auswahlhandlungen vor. Zuerst werden alle Angebote angefordert und kurz danach nur Workshops. Die erste Antwort kann später eintreffen als die zweite. Ohne Schutz würde dann möglicherweise die ältere Auswahl wieder erscheinen, obwohl die Person zuletzt Workshops gewählt hat.

Der Client beendet zunächst die bisherige Anfrage und vergibt eine neue Versionskennung. Vor der Übernahme einer Antwort wird geprüft, ob sie noch zur aktuellen Version gehört. Auch catch und finally berücksichtigen diese Kennung. Eine alte Anfrage darf deshalb weder eine neue Statusmeldung überschreiben noch die Beschäftigt-Kennzeichnung einer neueren Anfrage entfernen.

Dieser Zusammenhang ist wichtiger als die einzelne Verwendung von await. Asynchroner Code kann gut lesbar aussehen und trotzdem veraltete Ergebnisse übernehmen. Beschreiben Sie, welche Antwort noch zuständig ist und prüfen Sie genau diesen Fall mit bewusst unterschiedlicher Antwortreihenfolge.

Abbrechen bedeutet nicht, den Server rückgängig zu machen

AbortController ermöglicht den Abbruch entsprechender Webanfragen und des Lesens von Antwortdaten. Die Oberfläche kann dadurch auf eine neue Auswahl oder eine ausdrückliche Abbruchhandlung reagieren. Ein einmal abgebrochenes Signal wird im Beispiel nicht für eine neue Anfrage wiederverwendet.

Ein Abbruch auf der Clientseite garantiert nicht, dass ein Server eine begonnene Tätigkeit ebenfalls beendet oder rückgängig macht. Diese Grenze ist bei schreibenden Vorgängen besonders wichtig. Unsere Angebotsliste führt nur lesende GET-Anfragen aus. Eine Zahlung oder Buchung benötigt einen anderen fachlichen Vertrag mit ausdrücklich geprüftem Wiederholungsverhalten.

Der zusätzliche Versionsvergleich ist keine Ersatzberechtigung und kein Transaktionsmechanismus. Er schützt hier ausschließlich die Zuordnung zwischen einer Antwort und dem aktuell gewünschten sichtbaren Ergebnis. Diese Begrenzung sollte auch bei einer späteren Übernahme in eine größere Anwendung erhalten bleiben.

Ein Zeitlimit als eigenen Zustand behandeln

Das Beispiel markiert einen zeitbedingten Abbruch gesondert. Ein bewusstes Betätigen des Abbruchknopfs erhält eine andere Meldung als das Überschreiten der gewählten Wartezeit. Die bisherige Liste wird in beiden Fällen nicht stillschweigend als neu geladen ausgegeben. Wenn noch gar keine Daten vorlagen, wird auch dies ausdrücklich benannt.

Ein JavaScript-Timer ist kein harter Echtzeitnachweis. Wenn der Hauptthread blockiert ist, kann seine Ausführung später erfolgen. Ebenso beantwortet das Zeitlimit nicht, ob ein Server noch arbeitet. Die Funktion verwendet den Timer als Regel für die eigene Anfragebehandlung und nicht als Beweis über sämtliche beteiligten Systeme.

Jeder Timer wird bei Abschluss wieder aufgeräumt. Sonst könnte ein früherer Vorgang später noch eine Abbruchhandlung auslösen. Bei überlappenden Anfragen ist entscheidend, dass die jeweils eigene Aufräumarbeit nur die ihr zugeordneten Ressourcen betrifft.

Antwortformat und Datenstruktur getrennt prüfen

Der Medientyp ist ein erster Hinweis. Die Funktion normalisiert seine Schreibweise und ignoriert zusätzliche Parameter wie den Zeichensatz. Anschließend wird JSON gelesen. Laut MDN-Dokumentation zu Response.json() kann unter anderem ein Syntaxfehler auftreten, wenn der Antwortkörper nicht als JSON gelesen werden kann.

Gültiges JSON ist noch kein gültiger Angebotsdatensatz. Die Funktion prüft deshalb das erwartete Listenfeld, grundlegende Typen, Titel und Kennungen sowie doppelte Einträge. Ein unerwartetes Objekt wird nicht teilweise übernommen. Erst nach erfolgreicher Prüfung wird eine vollständige neue Liste aufgebaut.

Die Grenze von hundert Angeboten und die Zeichenlängen sind Regeln dieses Beispielvertrags. Sie begrenzen nicht automatisch die gesamte übertragene Datenmenge, weil die Antwort zu diesem Zeitpunkt bereits gelesen wird. Eine echte Schnittstelle benötigt zusätzlich passende serverseitige Grenzen. Auch fachliche Richtigkeit und Berechtigung werden durch diese Strukturprüfung nicht bewiesen.

Text als Text ausgeben

Die Titel werden über textContent in neu erzeugte Listenelemente geschrieben. Dadurch wird ein gelieferter Titel nicht als HTML-Anweisung interpretiert. Eine Zeichenfolge mit spitzen Klammern erscheint als Text und erzeugt kein zusätzliches Bild- oder Skriptelement. Für diese einfache Liste ist das die passende Ausgabeform.

Vermeiden Sie den Wechsel zu innerHTML allein aus Bequemlichkeit. Wenn eine Anwendung tatsächlich strukturierten fremden HTML-Inhalt benötigt, ist dafür ein eigenes Konzept mit geeigneter Bereinigung und einem klaren Vertrauensmodell erforderlich. Das ist ein anderer Vertrag als unsere Liste kurzer Titel.

Auch eine im Browser sicher dargestellte Information muss serverseitig für die richtige Person bestimmt sein. Darstellungssicherheit und Zugriffsschutz beantworten unterschiedliche Fragen. Die öffentliche Lernliste enthält deshalb keine vertraulichen Datensätze und behauptet keine Benutzerkontenverwaltung.

Fehler, leere Ergebnisse und alte Daten klar benennen

Diese Unterschiede verhindern eine häufige Irreführung: Aus fehlenden Daten darf nicht ohne erfolgreiche Prüfung die fachliche Aussage werden, es existiere nichts. Die Oberfläche sollte ihren Wissensstand mitteilen. Eine klare Meldung ist dabei hilfreicher als ein unkommentiertes leeres Feld oder ein erfundener Erfolg.

CORS nicht durch einen undurchsichtigen Abruf umgehen

Der relative Pfad unseres Beispiels gehört zur selben Origin wie die ausliefernde Seite. Wird später eine fremde Domain verwendet, müssen deren Freigaben und die übrigen Zugriffsbedingungen passen. Die MDN-Erläuterung zu CORS beschreibt die vom Browser durchgesetzte Herkunftsprüfung.

Eine Änderung auf no-cors ist kein allgemeiner Reparaturweg für einen Client, der lesbare JSON-Daten benötigt. Untersuchen Sie stattdessen die tatsächliche Serverantwort und Konfiguration. JavaScript erhält bei bestimmten Herkunftsproblemen nur begrenzte Fehlerdetails. Für die Diagnose werden daher auch Browserkonsole und Netzwerkanzeige benötigt.

Unterscheiden Sie diese Diagnose vom öffentlichen Fehlertext. Endnutzer brauchen eine verständliche Handlungsmöglichkeit. Interne Netzwerkdetails, Zugangsdaten oder vollständige vertrauliche Antworten gehören nicht pauschal in ihre Fehlermeldung.

Wiederholungen passend zur fachlichen Aktion planen

Die Liste bietet eine erneute Auswahl als ausdrücklichen weiteren Versuch an. Sie startet keine endlose Folge automatischer Anfragen. Für einen lesenden Abruf kann eine begrenzte Wiederholungsstrategie sinnvoll sein. Ihre Häufigkeit und Bedingungen müssen jedoch zum Dienst passen und dürfen ein bestehendes Problem nicht durch unnötige zusätzliche Last verschärfen.

Bei schreibenden Aktionen ist zuerst zu klären, ob der erste Versuch bereits wirksam war. Eine unklare Zahlungsantwort darf nicht wie eine fehlgeschlagene Angebotsliste beliebig wiederholt werden. Der Fetch-Standard beschreibt den technischen Mechanismus, liefert aber keine allgemeine fachliche Entscheidung über solche Geschäftsabläufe.

Behalten Sie diese Trennung bei Erweiterungen bei. Ein vorhandener Ladehelfer ist kein ausreichender Grund, jede Operation in dieselbe Fehlerbehandlung zu stecken. Gemeinsame Technik ist dann nützlich, wenn die Unterschiede des fachlichen Vertrags erhalten bleiben.

Den Lebenszyklus der Oberfläche berücksichtigen

Beim Verlassen der Seite wird die aktive Anfrage im Beispiel abgebrochen. In einer Anwendung mit wechselnden Komponenten muss zusätzlich deren eigener Abbau berücksichtigt werden. Ein Listener oder eine Anfrage sollte nicht unkontrolliert weiterlaufen, nachdem ihr zuständiger Bereich entfernt wurde.

Planen Sie dafür einen eindeutigen Eigentümer der laufenden Arbeit. Wer startet die Anfrage? Wer beendet sie bei einer neuen Auswahl? Wer räumt beim Entfernen der Ansicht auf? Diese Fragen verhindern schwer nachvollziehbare Rückmeldungen an bereits überholte Oberflächen.

Ein allgemeines Framework kann Teile dieses Lebenszyklus unterstützen. Die fachliche Erwartung bleibt trotzdem Ihre Aufgabe. Testen Sie einen Wechsel während einer laufenden Anfrage und nicht nur den ungestörten ersten Abruf.

Eine sinnvolle Prüfliste für asynchrones Verhalten

Die Browserprüfung dieses Beitrags führt die eingebetteten Sprachfassungen mit kontrollierten Antworten aus. Sie prüft sichtbaren Inhalt, Status und Beschäftigt-Zustand. Das ist ein begrenzter Funktionsnachweis des Clients. Er ersetzt weder einen Lasttest der echten Schnittstelle noch eine tatsächliche Untersuchung aller unterstützenden Technologien.

Eine leere HTTP-Antwort bewusst behandeln

Der Vertrag unserer Liste erwartet ein JSON-Objekt, auch wenn dessen offers-Liste leer ist. Eine Antwort ohne Körper erfüllt diesen Vertrag deshalb nicht automatisch. Beispielsweise kann ein erfolgreicher Status ohne Inhalt anschließend beim JSON-Lesen scheitern. Daraus sollte nicht stillschweigend die fachliche Aussage werden, für die Auswahl existierten keine Angebote.

Wenn eine echte Schnittstelle ausdrücklich einen solchen leeren Antworttyp vorsieht, wird sein Umgang gesondert in den Client aufgenommen. Entscheidend ist die vereinbarte Bedeutung. Ein Fehler im erwarteten Format und ein erlaubter leerer Zustand müssen nicht dieselbe Meldung erhalten. Schreiben Sie den Vertrag so konkret auf, dass beide Seiten ihre Antwort beziehungsweise Erwartung daran prüfen können.

Den Antwortkörper nicht versehentlich mehrfach verbrauchen

Eine Response ist nicht einfach eine beliebig oft neu lesbare Zeichenfolge. Das Lesen des Körpers ist selbst ein asynchroner Schritt. Wer die Antwort zunächst zur Diagnose als Text liest und danach nochmals als JSON lesen möchte, kann den zulässigen Zustand des Körpers bereits verändert haben. Die Dokumentation von Response.json() beschreibt entsprechende Fehlerfälle.

Unsere Funktion besitzt deshalb einen klaren Leseweg. Medientyp und Status werden aus den dafür vorgesehenen Eigenschaften betrachtet, danach wird der Körper einmal als JSON gelesen. Falls für eine Diagnose zusätzliche Verarbeitung nötig ist, muss diese bewusst entworfen werden. Vollständige Antwortinhalte ungeprüft in Protokolle zu schreiben ist außerdem keine geeignete Standardstrategie für vertrauliche Daten.

Die Schnittstelle unabhängig vom Browser prüfen

Ein Client mit gutem Fehlerverhalten kann einen fehlerhaften Server nicht richtig machen. Prüfen Sie, ob die tatsächliche Schnittstelle die vorgesehenen Ansichten versteht, passende Antworttypen liefert und Daten nur im erlaubten Umfang ausgibt. Eine im Browser festgelegte Auswahl ist kein Schutz davor, denselben Endpunkt mit anderen Parametern direkt aufzurufen.

Für die Übergabe zwischen Entwicklung und Betrieb gehören daher Beispielanfrage, Antwortvertrag und wichtige Fehlerzustände zusammen. Der hier getestete Client zeigt, wie eine Oberfläche darauf reagieren kann. Ob eine echte Installation diese Antworten erzeugt und welche betrieblichen Grenzen gelten, wird in ihrer eigenen Umgebung überprüft.

Fehlerbeobachtungen sinnvoll zusammenführen

Für den Betrieb ist nicht nur interessant, ob ein einzelner Abruf fehlgeschlagen ist. Wiederholt sich derselbe Fehler bei einer bestimmten Ansicht oder nur nach einer Änderung? Sammeln Sie dafür geeignete technische Hinweise im vorgesehenen Rahmen und trennen Sie sie von den sichtbaren Meldungen. Eine Vorgangskennung kann bei der Zuordnung helfen, ohne sämtliche Antwortinhalte zu vervielfältigen.

Die Untersuchung sollte außerdem unterscheiden, ob eine Anfrage abgebrochen, ein HTTP-Fehler empfangen oder die Datenstruktur unerwartet war. Diese Ursachen brauchen unterschiedliche nächste Schritte. Die gemeinsame verständliche Meldung für die Oberfläche darf deshalb nicht bedeuten, dass intern jede Diagnose auf dieselbe unbestimmte Aussage reduziert wird.

Checkliste für den nächsten fetch-Einsatz

• Lade-, Erfolgs-, Leer-, Fehler- und Abbruchzustände sind beschrieben.
• HTTP-Status und fachliche Antwort werden getrennt bewertet.
• Medientyp und erwartete Datenstruktur werden berücksichtigt.
• Ältere Anfragen können keine neuere Auswahl überschreiben.
• Aufräumarbeit betrifft nur die jeweils zuständige Anfrage.
• Text wird ohne unnötige HTML-Interpretation ausgegeben.
• Ein Zeitlimit wird nicht als Server-Rückabwicklung missverstanden.
• Wiederholungen passen zur fachlichen Aktion.
• Statusmeldungen sind auch programmatisch erkennbar.
• Die tatsächliche Schnittstelle und der Lebenszyklus werden gesondert geprüft.

Häufige Fragen zu asynchronen Listen

Warum reicht try/catch nicht? HTTP-Fehler müssen ausdrücklich berücksichtigt werden. Zusätzlich kann eine technisch erfolgreiche Antwort das falsche Datenformat oder einen überholten Auswahlstand betreffen. Diese Fragen liegen außerhalb eines bloßen Ausnahmefangs.

Sollte man die alte Liste immer leeren? Das hängt von der Aufgabe ab. Hier bleibt sie bis zur erfolgreichen Aktualisierung sichtbar und wird bei Fehlern ausdrücklich als unverändert benannt. Wichtig ist eine eindeutige nachvollziehbare Vereinbarung.

Ist Abbrechen für lesende Abrufe nötig? Es hilft bei unnötig gewordener Arbeit und verständlichen Zuständen. Entscheidend ist jedoch die gesamte Zuordnung zwischen Anfrage und sichtbarem Ergebnis. Der Controller allein beschreibt noch keine vollständige Oberflächenlogik.