[{"data":1,"prerenderedAt":43},["ShallowReactive",2],{"site-settings-batix":3,"batix-blog-auch-im-frontend-zahlt-sich-architektur-aus-vue-3-mit-type-script":22,"page-seo-\u002Fblog\u002Fauch-im-frontend-zahlt-sich-architektur-aus-vue-3-mit-type-script":12},{"id":4,"user_created":5,"date_created":6,"user_updated":7,"date_updated":8,"site_name":9,"site_url":10,"tagline":11,"default_og_image":12,"favicon":12,"organization_legal_name":13,"organization_email":14,"organization_phone":15,"organization_address_street":16,"organization_address_zip":17,"organization_address_city":18,"organization_address_country":19,"social_linkedin":20,"social_xing":21,"social_youtube":21,"social_instagram":21,"google_site_verification":12},"368daec2-c06c-4d64-bba7-feb859b94322","4686f9ba-fccc-4a50-9410-b80ae06ef0eb","2026-05-07T15:29:22.000Z","7d85c00d-d619-4d10-86a2-a469f8283bfc","2026-08-12T12:11:25.000Z","Batix","https:\u002F\u002Fbatix.swiss","Ihr Partner für IT-Beratung, Lösungen und massgeschneiderte Softwareentwicklung in der Schweiz.",null,"Batix Schweiz AG","info@batix.ch","+41 44 545 32 70","Grindlenstrasse 3","8954","Geroldswil","Schweiz","https:\u002F\u002Fwww.linkedin.com\u002Fcompany\u002Fbatix\u002F","",{"id":23,"title":24,"slug":25,"subtitle":26,"category":27,"cover_image":28,"lead_text":29,"definition":30,"content":31,"graphic":32,"graphic_caption":33,"faqs":12,"cta_text":34,"cta_label":35,"cta_url":36,"author":37,"published_at":38,"date_updated":39,"meta_title":40,"meta_description":41,"og_title":12,"og_description":12,"og_image":12,"canonical_url":12,"robots":42},"9b04766c-2cef-4cbd-afa2-79802de17def","Auch im Frontend zahlt sich Architektur aus: Vue 3 mit TypeScript","auch-im-frontend-zahlt-sich-architektur-aus-vue-3-mit-type-script","Wie Komponenten, Stores und ein API-Controller in Vue 3 dieselbe klare Trennung bekommen wie Controller, Service und Repository im Backend.","Development","6dee3b4a-c244-495b-a31c-3ff6f45e7de2","Schichtenarchitektur wird meist im Backend diskutiert: Controller, Service und Repository, sauber getrennt nach Verantwortlichkeit. Im Frontend sieht die Realität oft anders aus. Eine Komponente ruft die API direkt auf, verarbeitet die Antwort inline und rendert das Resultat, alles in derselben Datei.\n\nDabei gilt im Frontend dasselbe Prinzip wie im Backend, nur mit anderen Namen. Bei Batix wird das seit BX:EDUCATION konsequent mit Vue 3 und TypeScript umgesetzt: Komponenten übernehmen die Darstellung, Stores die Rolle des Service, ein Controller kapselt die API-Anfragen, und TypeScript-Models bilden ab, was an die API gesendet oder von ihr empfangen wird.","Auch im Frontend trennt eine Schichtenarchitektur Darstellung, Zustand und Datenzugriff in eigene Bausteine, in Vue 3 etwa Komponenten, Stores und einen API-Controller, verbunden über typisierte Models.","\u003Cp>\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Warum gewachsener Code irgendwann bremst Warum eine Komponente nicht auch die API kennen sollte\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Ruft eine Komponente die API direkt auf, verknüpft sie zwei Dinge, die eigentlich nichts miteinander zu tun haben: wie Daten dargestellt werden, und woher sie kommen. Ändert sich der Endpunkt, das Antwortformat oder die Authentifizierung, muss das in jeder Komponente angepasst werden, die diese Daten braucht. Nutzen mehrere Komponenten denselben Zustand, verwaltet ausserdem jede ihre eigene Kopie von Ladezustand, Fehlerbehandlung und Daten.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Bei Batix zeigt sich der Effekt einer klaren Trennung am deutlichsten, sobald eine Anwendung wächst. Debuggen und Erweitern sind bei sauber getrennten Schichten spürbar effizienter, als wenn Anzeige- und Datenlogik über viele Komponenten verstreut sind. Ein zusätzlicher Vorteil zeigt sich beim Testen: Lässt sich eine Komponente nicht von der API lösen, muss jeder Test die Netzwerkschicht mitsimulieren. Mit einem eigenen Controller lässt sich der Store isoliert testen, indem lediglich der Controller gemockt wird.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Component, Store, Controller, Model: die Rollen im Detail\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Die Component nimmt Nutzereingaben entgegen und zeigt Daten an, ähnlich wie der Controller im Backend Anfragen entgegennimmt. Der Store hält den Zustand und die Geschäftslogik, in der Rolle des Service. Der Controller im Frontend kapselt die eigentlichen API-Aufrufe, vergleichbar mit dem Repository, das im Backend die Datenbank kapselt. Das Model ist ein TypeScript-Interface, das exakt abbildet, was an die API gesendet oder aus ihr empfangen wird, in der Rolle des DTOs.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Ein Beispiel: Ein Formular zum Anlegen eines Kurses ruft im Store eine Methode wie createCourse auf. Der Store prüft, was inhaltlich nötig ist, und übergibt die Daten an den Controller. Der Controller baut daraus ein CourseRequest-Model, schickt es an die API und wandelt die Antwort in ein Course-Model zurück, bevor der Store seinen Zustand aktualisiert. Die Component selbst sieht von alledem nur den fertigen Zustand im Store.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Ohne diese Trennung landen API-Antworten im Code oft als any oder als lose typisiertes Objekt, TypeScript kann dann nicht mehr prüfen, ob ein Feld tatsächlich existiert. Mit einem eigenen Model-Typ pro Endpunkt meldet der Compiler dagegen sofort, wenn sich das Antwortformat ändert oder ein erwartetes Feld fehlt.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Warum sich das bei wachsender Software auszahlt\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Der Mehraufwand fällt zu Beginn auf: mehr Files, mehr Typisierung, mehr Zwischenschritte für denselben API-Aufruf. Bei einer kleinen Anwendung mit wenigen Komponenten ist das kaum zu rechtfertigen. Sobald eine Anwendung über mehrere Module und viele Komponenten wächst, kehrt sich das Verhältnis um: Eine Änderung an einem Endpunkt betrifft nur noch den Controller und das betroffene Model, nicht jede Komponente, die die Daten anzeigt.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Der Effekt zeigt sich auch im Team: Während die eine Person an der Darstellung einer Komponente arbeitet, kann eine andere Person parallel den Controller für einen neuen Endpunkt ergänzen, ohne dass sich beide Änderungen gegenseitig in die Quere kommen.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cem>\u003Cspan class=\"tm7\">Sascha, der das Muster bei Batix auch im Frontend eingeführt hat:\u003C\u002Fspan>\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp class=\"Normal tm8 tm9\">\u003Cem>\u003Cspan class=\"tm7\">«Debuggen und Erweitern sind bei einer grossen Software mit sauber getrennten Schichten spürbar effizienter, als wenn API-Logik und Zustand über viele Komponenten verstreut sind.»\u003C\u002Fspan>\u003C\u002Fem>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Warum gewachsener Code irgendwann bremst Wo die Analogie zum Backend nicht ganz passt\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Eine Einschränkung bleibt: Ein Store ist kein reiner Service wie im Backend, sondern reaktiver Zustand. Ändert sich ein Wert im Store, aktualisiert Vue automatisch jede Komponente, die ihn verwendet. Diese Reaktivität ist im Frontend ausdrücklich gewünscht, sie unterscheidet den Store aber von einem zustandslosen Backend-Service, der bei jedem Aufruf neu ausgeführt wird.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Wer die Analogie zu wörtlich nimmt, versucht unnötig, Reaktivität aus dem Store herauszuhalten, obwohl sie genau der Grund ist, warum der Store überhaupt existiert. Die Rollenaufteilung stimmt, die technischen Eigenschaften der einzelnen Bausteine bleiben trotzdem framework-spezifisch.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Für Logik, die keinen geteilten Zustand braucht, bietet sich statt eines Stores oft ein Composable an, eine wiederverwendbare Funktion mit eigenem, lokalem Zustand. Die Rollenaufteilung zwischen Controller und Model bleibt dabei gleich, nur die Service-Rolle wandert vom Store in das Composable.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp>\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Fazit\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Das Prinzip lässt sich auf jedes komponentenbasierte Frontend übertragen, unabhängig vom gewählten Framework: Darstellung, Zustand und Datenzugriff gehören in getrennte Bausteine, verbunden über klar typisierte Schnittstellen. Bei Batix ist das mit Vue 3 und TypeScript inzwischen Standard für neue Frontend-Projekte, und die Erfahrung aus dem Backend fliesst dabei direkt in die Frontend-Architektur mit ein.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"MsoNormal\" style=\"margin-bottom: 8.0pt;\"> \u003C\u002Fp>\n\u003Cp class=\"MsoNormal\" style=\"margin-bottom: 8.0pt;\">\u003Cspan style=\"font-size: 11.0pt; color: #222222;\">\u003Cspan style=\"color: #2e5b7f;\">\u003Cstrong>Häufig gestellte Fragen \u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"MsoNormal\" style=\"margin-bottom: 8.0pt;\">\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Was übernimmt der Store in dieser Architektur?\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Der Store übernimmt die Rolle des Service: Er hält Zustand und Geschäftslogik und delegiert den eigentlichen Datenzugriff an den Controller. Komponenten lesen und verändern Daten ausschliesslich über den Store, nie direkt über die API.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Was macht der Controller im Frontend?\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Er kapselt die API-Aufrufe, vergleichbar mit dem Repository im Backend. Anfragen und Antworten laufen dabei über typisierte Models, sodass der Rest der Anwendung nichts von den Details der Schnittstelle wissen muss.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Was macht der Controller im Frontend? Wozu dienen die TypeScript-Models?\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Sie bilden ab, was an die API gesendet oder von ihr empfangen wird, in der Rolle des DTOs im Backend. Der Compiler prüft dadurch schon beim Schreiben des Codes, ob eine Anfrage oder Antwort zur erwarteten Struktur passt, statt den Fehler erst zur Laufzeit im Browser sichtbar zu machen.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Lohnt sich das auch für kleine Vue-Projekte?\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">Bei sehr kleinem Umfang steht der Mehraufwand an zusätzlichen Files und Typisierung oft in keinem guten Verhältnis zum Nutzen. Sobald ein Projekt über mehrere Module, mehrere Personen im Team und einen längeren Zeitraum wächst, zahlt sich die Trennung aus.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cspan class=\"tm6\">\u003Cstrong>\u003Cspan style=\"color: #2e5b7f;\">Ist ein Store dasselbe wie ein Backend-Service?\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\">\u003Cstrong>\u003Cspan class=\"tm7\">ANTWORT 5\u003C\u002Fspan>\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp class=\"Normal tm8\">\u003Cspan class=\"tm6\">Nicht ganz: Ein Store ist reaktiver Zustand, ein Backend-Service meist zustandslos. Die Aufgabentrennung, die beide Muster verfolgen, bleibt aber dieselbe.\u003C\u002Fspan>\u003C\u002Fp>\n\u003Cp class=\"Normal tm5\"> \u003C\u002Fp>\n\u003Cp class=\"Normal tm5\"> \u003C\u002Fp>","02e175d5-075f-466e-9799-7384b67d899a","Der Datenfluss im Frontend: Component, Store, Controller, Model, API.","Wer eine bestehende Vue-Anwendung modernisieren oder ein neues Frontend von Grund auf sauber strukturieren will, findet in der individuellen Softwareentwicklung der Batix den passenden Ansprechpartner.","Kontakt aufnehmen","\u002Fcontact","Sascha Wechsler","2026-10-05T11:55:00.000Z","2026-10-05T11:55:56.000Z","Schichtenarchitektur im Frontend: Wie Vue 3 und TypeScript von klarer Trennung profitieren","Das Ziel-Keyword «Vue 3 Architektur TypeScript» ist eng gefasst und trifft eine klare Suchintention, während generische Begriffe wie «Frontend-Architektur» stark umkämpft und meist React-lastig sind. Vue und TypeScript stehen zudem als Technologien in den offiziellen Batix-Claims, was den Artikel glaubwürdig an die eigene Kompetenz koppelt. Der Meta-Titel greift bewusst «Schichtenarchitektur» aus Artikel 1 auf, um die Serie auch im Suchergebnis erkennbar zu machen.","index,follow",1791210734618]