Design Patterns - MVC.

Hallo und herzlich willkommen zu einer neuen Folge in unserem Webcafé, dem wöchentlichen Podcast rund um Webtechnologie und Unternehmenskultur.

Und wie bisher immer machen den Podcast heute für euch der Kay. Hallo, das bin ich. Hallo. Und ich bin der Felix. Wir sind beide bei der Gen-IT-Systeme GmbH in Dortmund beschäftigt und haben heute ein ganz besonderes Thema für euch mitgebracht.

Oder ich muss es vielleicht anders sagen. Wir starten heute eine Serie und zwar geht es da um Design-Patterns. Das habe ich, glaube ich, in dem Podcast immer wieder schon mal erwähnt, dass mir daran gelegen wäre, weil es eben ganz viele Design-Patterns gibt, die wir euch gerne vorstellen würden, die wir benutzen.

Und bevor wir da aber tiefer einsteigen, gucken wir mal, was der Kay als Getränk mitgebracht hat. Ich kann heute leider gar nicht so etwas Fanciers erzählen. Ich habe ja immer das Problem, dass so Teesorten eine gewisse Volumen haben.

Ich muss sich erst da durchtrinken, um was Neues aufmachen zu können. Und deswegen habe ich jetzt heute mal wieder bis zum Ellenbogen quasi in unsere Box mit dem Pfefferminztee gegriffen und mir einen frischen Pfefferminz aufgesetzt.

Der sitzt jetzt hier so in meinem Glasgefäß und hat so eine güldene Farbe, das reflektiert. Also man kann auch fancy beschreiben, was schlicht ist. Aber was trinkst du? Das ist natürlich ein absoluter Klassiker, Pfefferminztee. Bin ich nicht der größte Fan von diesen Basic-Tees. Ich habe dagegen so ein bisschen was Besonderes mitgebracht. Ich habe nämlich einen ostfriesischen Sonntagstee dabei. Der ist mit echter Vanille. Das hat mich natürlich direkt abgeholt, als ich das gesehen habe.

Und die Packung sagt, dass die Vanille dabei aber nur eine Aromabereicherung sein soll und der Tee nicht wirklich nach Vanille schmecken soll.

Also das ist wirklich so ein Hauch Vanille. Und dass das Ding Sonntagstee heißt, das erklärt sich daraus, dass die Vanille eben früher sehr teuer war. Und die Ostfriesen sich deswegen das vielleicht nur am Sonntag leisten konnten und das auf einen Tag beschränken mussten mit dem Konsum von dieser echten Vanille dann.

Und ein kleiner Funfact vielleicht noch dazu. Auf der Seite von dem Teehersteller habe ich gelesen, ich zitiere sogar, Dabei legt man die Sahne gegen den Uhrzeigersinn in den Tee, um sinnbildlich die Zeit anzuhalten.

Aber ich habe es jetzt noch nicht verstanden. Vanille ist drin, okay. Aber ansonsten ist das ein Schwarztee oder was ist das für ein Gebräu? Genau, das ist ein ganz normaler Schwarztee und mit einem Hauch Vanille dann tatsächlich. Ah ja, okay. Und ja, ich habe mir jetzt auch zwar keine Sahne, aber eine 3,8%ige Milch diesmal reingemacht. Natürlich gegen den Uhrzeigersinn. Nein, gegen den Uhrzeigersinn, um die Zeit anzuhalten. Oh Gott. Ich habe da was für über, wenn man da so ein bisschen sich mit beschäftigt. Das nächste Mal muss ich mir auch blümerannte Beschreibungen für meinen schnöden Tee überlegen.

Für deinen Pfefferminztee, ne? Naja. Gülden geleckt aus Bernstein. Kay, wir wollen uns heute als erstes Design-Pattern oder auch Entwurfsmuster das MVC angucken,

Model View Controller. Aber bevor wir darauf eingehen, wollen wir erstmal von dir wissen, was Design-Pattern überhaupt sind. Ja, genau. Du hast das eingangs schon erwähnt. Als Entwickler, glaube ich, als Software-Entwickler kommt man ja gar nicht drum herum, im Laufe seiner lernenden Karriere mit so Design-Patterns konfrontiert zu werden. Und zumindest bei mir war dann immer der Ablauf relativ gleich. Ich habe gehört, hier gibt es ein neues Design-Pattern. Und dann habe ich mir im Internet angeschaut, was da steht. Und da steht er in einem super kompliziertem Text mit super kryptischen Beispielen, dass das

total wichtig ist, aber so richtig verstanden habe ich es nicht. Und dann habe ich es wieder vergessen und einfach so von mich hin programmiert. Und erst im Laufe der Zeit, jetzt wieder in den jüngeren Jahren, wenn ich mich wieder mehr mit Software-Architektur und so weiter beschäftigt habe, habe ich immer wieder festgestellt, okay, das sind ja eigentlich schon Design-Patterns, die wir da ganz automatisch abbilden, auch wenn wir es nie so gemacht haben. Und mein Ansatz jetzt für diese Serie ist, jetzt einen zugänglichen Ansatz für Design-Patterns zu finden, die man so im Alltag benutzen kann. Da kommen wir ja her.

Wir wollen also nicht die Fachliteratur rezitieren, sondern vielleicht so ein bisschen einen alltagsbezogenen, etwas anderen Ansatz finden. Da kann ich vielleicht einwerfen von mir. Meine ersten Berührungen mit Design-Patterns waren nämlich Kommentare von anderen Entwicklern, von erfahreneren Entwicklern. Und dann kamen da so Zitate wie, ja, da gibt es auch einen Pattern für, wenn man irgendein Problem hatte. Oder, ah, das ist ja eine Factory zum Beispiel, wo ich dann natürlich nicht wusste, was eine Factory ist in dem Moment. Aber da hatte ich wohl irgendwas entwickelt, was einem Design-Pattern zumindest ähnlich war.

Genau, und deswegen aus der Praxis raus finde ich einen richtig guten Ansatz. Genau, und das ist auch der Trick. Bei diesen Patterns handelt es sich nicht um irgendwelche strengen Vorgaben, die das heilige Konsortium der Programmierung gemacht hat und an die wir uns halten müssen, sondern Patterns, da steckst du schon im Namen, da geht es um Muster. Und wenn man ein bisschen entwickelt hat, dann stellt man fest, obwohl die Projekte, die man so bastelt, eigentlich total individuell und für den Kunden zugeschnitten sind, haben die eigentlich die gleichen Bausteine, die gleichen Probleme, die gleichen Hindernisse und auch

die gleichen Wege, damit umzugehen. Und diese Patterns, Design-Patterns sind eben ein Weg, um solche regelmäßig auftretenden Eigenschaften, Probleme oder wie auch immer im Code zu beschreiben, zu erkennen und dann einen einheitlichen Umgang damit zu finden. Einfach, weil diese Probleme immer wieder aufkommen und es nicht so richtig sinnvoll ist, da regelmäßig das Rad neu zu erfinden. Aber auch, wenn man dann erstmal von diesen Patterns weiß, man sie direkt im Code wiederfindet und dann so Schema im Kopf drauf anlegen kann. Ich finde deswegen auch wichtig, dass man bei diesen Patterns versteht, was das Konzept

dahinter ist, um dann zu überlegen, was jetzt in dieser konkreten Situation, die ich hier als Entwickler habe, das richtige Vorgehen ist. Statt, dass man sich wirklich haargenau an diese Lehrbücher hält, weil zumindest aus meiner Erfahrung, jetzt habe ich nicht alle gelesen, aber sind die immer ein bisschen kritisch und steif und unflexibel formuliert, obwohl die Konzepte dahinter eigentlich sehr gut sind. Und heute mit dem MVC-Pattern wollen wir vielleicht beschreiben, wie man dann dieses relativ starre MVC-Konstrukt auch auf vielleicht Programmier-Sachen übertragen kann, wo es vielleicht nicht

so naheliegend ist. Da würde ich dir sogar fast so ein bisschen widersprechen, weil ich so das Gefühl habe, viele Design-Patterns werden heute auch sehr flexibel ausgelegt und man findet ganz viele verschiedene Ausprägungen. Gerade beim MVC, Model-View-Controller, sage ich auch, glaube ich, jetzt im Anschluss noch mal kurz was dazu. Da gibt es auch inzwischen so Alternativen wie MVVM, Model-View, View-Model und sowas, das dann so Probleme behandelt, die wir bestimmt auch gleich noch mal kurz anreißen, dass man nicht ganz genau weiß, wo die Geschäftslogik hinkommt. Und solche Geschichten sind da Probleme, die man immer wieder mit dem MVC dann hat.

Und ich habe so das Gefühl, es gibt so ganz unterschiedliche Ausprägungen und man kann sich schon ein bisschen da das rauspicken, was für einen selbst ganz gut passt. Wenn es für jeden Use Case dann wieder ein eigenes Pattern gibt, dann weicht dir das Konzept auch wieder ein bisschen auf. Aber dann fang doch vielleicht an jetzt beim MVC, wo du schon eingestiegen bist und erzähl uns dazu was. Ja, wir haben das Wort jetzt schon viel zu oft dafür gesagt, dass wir noch nicht erklärt haben, was es ist. Also das MVC ist natürlich ein Entwurfsmuster, wie man auf Deutsch sagt, also ein Design-Pattern und steht dann für die englischen Begriffe Model, View und Controller.

Wenn man das jetzt runterbricht, geht es eigentlich nur darum, dass die Anwendungslogik unterteilt wird in drei miteinander verbundene Komponenten. Und das ist dann eben einerseits das Modell, da kommen die Daten oder das behandelt die Daten und die Geschäftslogik. Dann gibt es die Ansicht, das ist die View natürlich. Das ist letztlich die Benutzeroberfläche und dann gibt es den Controller, der verarbeitet die Benutzereingaben und aktualisiert das Modell und die Ansicht. Ich fasse das immer gerne zusammen durch Modelspeicherung oder Datenspeicherung im Model, Darstellung im View und dann Datenverteilung beziehungsweise Bearbeitung im Controller.

Da wird es schon schwammig. Genau. Das ist jetzt wahrscheinlich, wenn man den Podcast hört und vielleicht MVC das erste Mal hört, ein bisschen schwer verständlich. Deswegen haben wir uns gedacht, wir machen ein kleines Beispiel. Und am besten kann man das wahrscheinlich an so einem Kontaktformular darstellen. Wir wollen ja thematisch auch ein bisschen in der Webentwicklung bleiben. Und wenn wir uns jetzt ein einfaches Kontaktformular auf der Website vorstellen, dann wird dieses Kontaktformular selbst ja in HTML von der View angezeigt. Also der Benutzer sieht dieses Kontaktformular, kann jetzt Daten eingeben.

In dem Moment, wo die Daten abgeschickt werden, empfängt der Controller diese Daten. Also das ist letztlich der Programmteil. Dann eben Backend in den meisten Fällen, kann aber natürlich auch im JavaScript sein. Also im Frontend, der die Daten empfängt und sie letztlich weiter verteilt. Und in dem Moment würde es wahrscheinlich an ein Model gehen, das die Informationen in der Datenbank in meinem Modell jetzt speichert und eine Information zurückgibt an den Controller. Also beispielsweise, das hat geklappt, gibt ein OK zurück. Und der Controller wiederum ruft jetzt eine Success View auf, also so ein Erfolgsbildschirm

oder gibt eine kleine Nachricht aus, gibt eine Variable der View mit, dass das Ganze funktioniert hat. Und dann sind wir wieder in der View und der Kreis schließt sich. Also so arbeiten letztlich diese drei Elemente dann zusammen. Genau, das ist jetzt ein Ablauf, von dem man vielleicht intuitiv sagt, ja, ist doch total logisch, dass man das so macht. Aber wichtig ist ja nochmal hervorzuheben, dass es wirklich darum geht, diese drei Bereiche MVC auch wirklich so streng es eben geht zu trennen. Und das machen wir für ein paar Vorteile, auf die wir gleich noch eingehen. Aber der größte Vorteil ist eben, dass man diese Dinge streng trennt, um für jeden einzelnen

Baustein, den View und den Controller und das Model, die idealste Ausprägung zu finden. Und das hat dann bei dir zum Beispiel die Ausprägung, dass wir im Model wirklich nur die reinsten Daten aus diesem Formular speichern, die es gibt, in der reinstmöglichen Form und in der flexibelstmöglichen Form. Und in der View wird sie dann nur angezeigt, statt dass wir irgendwie in der Datenbank schon speichern, welche Farbe denn der Name hat, wenn wir sie in dem Formular anzeigen oder sowas. Also streng getrennt, so gut es geht. Und dabei entstehen natürlich schon die ersten Probleme, denn wenn du sagst, das wird

jetzt streng getrennt, dann gibt es trotzdem ja Fälle, in denen das nicht ganz klar ist, wo jetzt was behandelt wird. Klassisches Beispiel ist eine Datumsformatierung. Mache ich das jetzt schon in einem Model oder einer Datenbank, formatiere ich da das Datum schon oder mache ich das in einer View, weil das vielleicht auch in irgendeiner Form benutzerabhängig ist? Und da kann man sich dann vortrefflich drüber streiten, an welchen Stellen das dann hingehört. Aber prinzipiell versuchen wir schon, eine scharfe Trennung dann herzustellen. Ich finde, das ist ein gutes Beispiel, weil ich finde, da ist die Aufteilung total

klar, dass es in der Datenbank in der reinstmöglichen Form sein sollte. Also jetzt vielleicht so ein Timestamp, Unix-Timestamp oder vielleicht schon irgendein UTC-ISO-Timestamp-Format

oder sowas. Weil die Idee ist ja eben, dass man die Views beliebig austauschen kann. Und für einen Nutzer, der dann dieses Formular sieht, für den ist vielleicht ein deutsch formatiertes Format sinnvoll mit Tag und Monat, wenn es im selben Jahr ist oder sowas. Während die API, die ja auch eine Art von View anspricht, aber dann eben kein formatiertes HTML zurückbekommt, sondern einen JSON, das ist wiederum an den rohen Daten interessiert, um das weiter zu verarbeiten. Das heißt, da ist die eigentliche Speicherung der Daten unabhängig von der Darstellung und deswegen sollte da auch im Model das Datum in der reinstmöglichen Form stehen und dann

im View vielleicht Anpassungen für den Nutzer, der es gerade liest. Gehe ich insofern mit, als dass ich sagen würde, in der Datenbank sollte es tatsächlich beispielsweise als Timestamp, also in der reinstmöglichen Form, gespeichert werden. Ich will aber ja per Definition eigentlich in der View keine Geschäftslogik haben und in dem Moment, wo ich in der View das Datum formatiere, zum Beispiel anhand von irgendwelchen Benutzerinformationen oder so, könnte man das ja für Geschäftslogik halten und deswegen vielleicht sinnvoll ein Model platzieren. Aber wenn ich darüber nachdenke, würde ich deinen Ansatz vielleicht sogar mitgehen.

Genau, das wird dann nachher noch total spannend, wenn man die View aufteilt in verschiedene Module, innerhalb deren man die Information wieder weiterschleust. Aber das führt jetzt ein bisschen zu weit. Genau, man muss ja da wirklich auch dazu sagen, in der Praxis gibt es eben auch nicht nur diese drei Elemente, also Model View und Controller, sondern wir haben oft noch Hilfsdateien, wo man dann Funktionen, Objekte hat, die man zwischen verschiedenen Komponenten auch austauscht und dann wird die Trennung da natürlich manchmal auch aufgeweicht. Genau, das habe ich ja eingangs gesagt. Wichtig ist, das Konzept zu verstehen, diese Trennung zu forcieren wegen der Vorteile, die

wir gleich nennen und die wir auch teilweise schon gesagt haben. In der Realität kann man natürlich dann schauen, okay, jetzt in diesem einen konkreten Use Case macht es total Sinn, Logik da und dahin zu verschieben, vielleicht im View selber oder sonst irgendwas. Was ist denn für dich der größte Vorteil vom MVC? Ich habe nämlich einen im Kopf, vielleicht haben wir da den gleichen. Der größte Vorteil, den habe ich gerade schon so angedeutet, das ist nämlich die Unabhängigkeit. MVC bedeutet eben diese Aufteilung von der Handhabung von Daten, nämlich Speicherung, Kontrolle, wenn man so möchte, und Darstellung.

Und jeder Baustein hat möglichst wenig mit dem anderen zu tun. Thema Tide und Loose Coupling. Also die haben keine Abhängigkeiten voneinander mehr, als sie müssen. Und das führt dazu, dass die einzelnen Bausteine sehr losgelöst sind, unabhängig voneinander, dass man für jeden Baustein die beste Implementierungsform wählen kann, ohne dass man sich im View Gedanken darüber machen muss, wie dann Informationen im Model vorliegen zum Beispiel, oder umgekehrt. Dass ich im Model Informationen für die View vorhalten muss, obwohl sie eigentlich gar nicht da reingehören. Sowas wie Schriftfarbe oder Schriftgröße oder sowas.

Und dadurch kann ich sehr schön eine Anwendung bauen, die skalierbar ist, eben durch diese einzelnen, unabhängigen Bausteine. Interessant. Ich hätte einen anderen Punkt gesagt. Wenn ich so in die Anfänge meines Programmiererdaseins zurückgucke, dann hat mir das nämlich wahnsinnig geholfen, dass bestimmte PHP-Frameworks, ich habe damals mit Symfony zum Beispiel gearbeitet, aber auch ganz viele CMS, also Content-Management-Systeme, basieren ja dann letztlich auf dem MVC-Pattern.

Und mir hat das wahnsinnig geholfen, dass die Programme alle ähnlich strukturiert waren. Und ich immer mich so ein bisschen im Code zurechtgefunden habe sofort, weil die Struktur ähnlich war. Und das ist so das, was ich heute auch als größten Vorteil darstellen würde, dass man auf einen Blick im Code, in der Codestruktur sieht, ah, das ist MVC und das sind für mich zumindest die allermeisten Anwendungen,

die heute so geschrieben werden. Und ich finde mich relativ schnell zurecht, wo ich zum Beispiel Views finde, wo ich Controller finde, die dann mit den Daten erstmal umgehen, also immer ein guter Einstiegspunkt, in den Code reinzukommen. Und dann natürlich die Models, die mit der Datenverarbeitung zu tun haben. Das ist meistens ganz gut zu finden und das hilft mir am meisten beim MVC. Das stimmt. Insbesondere, weil das so ein verbreitetes Pattern ist, haben die meisten Frameworks da schon ihre eigenen Ansätze drauf. Wir benutzen ja viel Laravel und da ist MVC ja total tief verankert. Und das hilft natürlich total, was du gesagt hast, sich im Projekt zu orientieren.

Wenn es alle so machen, kann ich in jedes Laravel-Projekt rein und es funktioniert gleich. Und auch wenn wir gleich darüber reden, wie man das Konzept vielleicht übertragen kann auf andere Bauteile, wo das vielleicht nicht so offensichtlich ist, dann ist das auf jeden Fall auch ein Vorteil. Und ich finde eben einen wahnsinnig großen Vorteil, das ist jetzt aber nicht MVC-exklusiv, sondern allgemein für Design-Patterns, ist, dass alle die gleiche Sprache verwenden. Also in dem Moment, wo ich dann zum Beispiel über eine Factory rede oder eben über ein MVC oder ein Model oder ein Controller, da weiß jeder direkt, was gemeint ist.

Und früher hatte ich oft Probleme, dass ich Sachen schlecht beschreiben konnte in der Programmierung. Dann sage ich, ja, ich habe hier ein Objekt, das nimmt die Daten an und guckt, dass ein anderes Objekt angefragt wird, was aus der Datenbank die Daten holt. Und das ist halt so ein Rumgeschwafel. Und mit einem Pattern kann man es oft sehr, sehr präzise ausdrücken, was man eigentlich meint. Wir haben schon mal in einem vorherigen Podcast darüber, naja, uns ausgelassen, wie kompliziert es ist, Dinge zu benennen. Und da stimmt es natürlich, wenn man sich an so einer Vorlage orientiert, dann sind schon mal mindestens drei Begriffe klar und man kann sie auch so im Code verwenden.

Ich finde, ein Riesenvorteil von der Verwendung von MVC ist, das ist eigentlich so ein Vorteil, der da rausputzelt, wenn man das verwendet,

ist, dass man den Code auch besser testen kann. Weil wir gerade in Laravel finden, dass man die Controller eher schlecht testen kann, während man so ein Model zum Beispiel oder ein Model, sagen wir mal, kann man eben deutlich besser testen, wenn da die Geschäftslogik separiert ist, als wenn man jetzt in einem Controller rumtestet, was manchmal ein bisschen schwieriger ist. Genau, das zahlt ja voll in diesen Punkt ein, den ich eingangs gesagt habe, nämlich die Unabhängigkeit oder das Lose-Coupling der Bauteile. Und eben zum Testen kann ich dann sehr einfach die einzelnen Bauteile austauschen und sagen,

wenn ich jetzt nur die View testen möchte, dann baue ich in meinem Testszenario halt selber einen Controller und ein Model dahinter, so wie ich es brauche und kann dann die View unabhängig testen, genauso wie ich es auch mit dem Controller und mit dem Model machen kann. Und da geht dann auch das Thema Mocking rein, also Programmbestandteile in bestimmten Szenarien durch andere austauschen. Und wenn die eben nicht so nah aneinander gebunden sind, also ich sage es gerne nochmal, aber ich in der Datenbank nicht schon irgendwelche Sachen berücksichtigen muss, die nachher für die View entscheidend sind, dann kann ich das auch sehr schön trennen und einzelne Bauteile testen.

Ja, diese Austauschbarkeit würde ich definitiv auch noch als Riesenvorteil ansehen, weil man natürlich auch später, wenn man mal ein Refactoring macht oder so, auch einzelne Teile rausnehmen kann, durch andere ersetzen kann, weil sie eben nicht so fest miteinander verbunden sind. Genau, und ich muss auch nicht die Sorge haben, dass wenn ich jetzt in der View irgendwas ändere, in der Darstellung von Daten, dass das aus irgendwelchen komischen Gründen Auswirkungen auf meine Daten hat, genauso wie ich meine Daten nur für sich benutzen kann, also denken wir an das Kontaktformular, da ist dann das Model wirklich nur Name, Vorname, E-Mail-Adresse und nicht noch irgendwas für die Darstellung.

Und dadurch muss ich keine Angst haben, dass ich da jetzt an der Hintergrundfarbe was ändere und die View geht kaputt, obwohl wir eigentlich in einem ganz anderen Teil der Anwendung sind. Genau. Ich glaube, damit haben wir schon eine ganze Menge Vorteile genannt. Ich würde vielleicht noch eine kleine kniffligere Frage für dich stellen, weil sie mich persönlich interessiert, ist mir so in der Vorbereitung untergekommen. Ja, sehr gerne. Und zwar die Validierung der Benutzereingabe. Sag mal deine Gedanken dazu. Wo passt das hin? Kriegt man das MVC klar untergebracht? Also, ja, ich würde sagen, Validierung,

das hängt jetzt ein bisschen davon ab, aber klassische Validierung ist ja wirklich, dass man versucht, ein Model zu manipulieren und dann zum Beispiel testen möchte, dass der Kontaktformular-Beispiel, dass das Feld für die E-Mail-Adresse nicht länger ist, was den Input angeht, als das Feld, wie ich es in der Datenbank speichern kann. Und dann macht die Datenbank eigentlich die Validierung, wenn man so möchte, sofern sie kann. Und da am nächsten dran ist eben das Model als Repräsentation der Datenbank. Und das Model weiß, okay, ich habe ein Feld E-Mail-Adresse zum Beispiel und die Bedingungen dafür sind, es muss ein String sein, es darf nicht leer sein,

maximal 250 Zeichen und es muss ein bestimmtes Regex-Format haben. Und das gilt ja für das ganze Model, egal wo in der Anwendung das verwendet wird, ob es jetzt durch diese View oder diese View oder diese View angesteuert wird. Ich habe das Beispiel genommen, weil mir das natürlich so im Rahmen dieses Kontaktformulars aufgefallen ist und ich finde das interessant, weil ich nämlich sagen würde, das steckt ja in allen Elementen von dem MVC, weil du einerseits ja im Kontaktformular selbst schon eigentlich eine Frontend-Validierung machen musst. Das ist fast so ein bisschen die View, die dann schon die Benutzereingabe validiert.

Bei einem HTML-Input-Feld kann man ja dann angeben, dass zum Beispiel Numbers eingegeben werden können oder sowas in der Richtung. Dann hast du im Controller oder du könntest theoretisch im Controller auch nochmal die Benutzereingabe validieren im Sinne von, ich gucke, ob überhaupt Daten da sind, als ein Beispiel. Im Laravel ganz konkret haben wir ja sogar noch einen Request dazwischen, der dann nochmal eine Überprüfung, also eine konkrete Überprüfung macht, zum Beispiel auf eine Zeichenlänge oder auf einen Zahlenbereich. Und dann natürlich ganz, wie du richtig gesagt hast, ist die Datenbank so ein bisschen die letzte Instanz oder das Model,

dass die Datenbank wirklich einen String ablehnt, wenn es ein Integer-Feld ist oder was in der Richtung. Genau, das ist ein bisschen knifflig und du hast schon recht, bei Laravel ist es wirklich vor dem Controller noch geschaltet, aber das kann eben auch Probleme erzeugen, wie zum Beispiel, dass du zwei verschiedene Controller-Methoden hast oder zwei verschiedene Controller hast, die eigentlich dasselbe Model manipulieren, aber dann zwei verschiedene Requests haben, die unterschiedliche Bedingungen für das E-Mail-Feld anstellen können oder sowas. Da hat dann tatsächlich, glaube ich, jedes Framework so ein bisschen einen eigenen Ansatz dafür,

aber das zeigt eben auch, dass es nicht so ein starres Konzept ist, dass man überall einfach draufstempeln kann, sondern A, überlegen, was gibt das Framework vielleicht schon vor, das wir hier benutzen und B, was ist denn sinnvoll für unseren Use Case? Auf jeden Fall. Ich habe noch ein Gedankenspiel, nämlich bei unserem Tech-Stack ist es ja so, dass wir oft im Backend Laravel verwenden mit PHP, dann API Speisen, die dann von einer Frontend-Anwendung konsumiert wird und das ist dann in unserem Fall oft React mit TypeScript. Und da muss man ja sagen, und das ist eben in ganz vielen Anwendungen so,

dass wir oft nicht ein MVC haben für eine Anwendung, sondern dass eine Anwendung oft aus ganz vielen kleineren MVCs besteht. Und wenn man jetzt bei diesem Beispiel bleibt, ist eigentlich klar, dass wir im Frontend schon eine Art MVC haben und im Backend dann auch und wahrscheinlich innerhalb der Bereiche sogar dann auch nochmal weiter aufgeteilt, wenn man in die Module dann wirklich reingeht. Das ist ganz gut, dass du es sagst, weil das ist nämlich auch das eben Spannende an diesem MVC-Dingen. Wenn man so über Laravel und Backend redet, dann liegt einem das MVC-Konstrukt sehr viel näher, weil man da dann auch wirklich das abbildet

im Sinne von vielleicht Java oder C, was ja so die klassischen MVC-Frameworks sind, sage ich mal. C jetzt wahrscheinlich schon nicht. Worauf ich hinaus will ist, fürs Frontend ist es vielleicht nicht so naheliegend, aber ich finde genau diese Ideen, die man hat vom MVC, die Trennung zwischen diesen Dingern, kann man auch im Frontend genauso umsetzen. Und dann hat man vielleicht zwei kleinere MVCs, einmal fürs Backend, einmal fürs Frontend. Ich würde es vielleicht einmal beispielhaft an so einer Frontend-Komponente durchexerzieren, wie man da das MVC-Pattern übertragen kann, weil das ist, glaube ich, auch relativ stark,

aber nicht so offensichtlich wie im Backend. Wir stellen uns dafür mal so eine React-Komponente vor, was ja unser Frontend-Framework der Wahl ist und da bilden wir den M, also den Model-Aspekt ab, indem wir sagen, im Kopfbereich so einer React-Komponente, wir benutzen da funktionale Komponenten, haben wir zum einen die Datenspeicherung, in Anführungszeichen, die zum Beispiel über Props kommt oder über States, Kontext und sowas. Das machen wir auch gerne dann optisch im Kopf der Anwendung, dass das da zusammen ist. Da werden also die Daten gespeichert, wie im Model. Dann kommt ein Block, in dem das Controlling passiert,

also irgendwelche On-Click-Listener und Filter und solche Dinge. Und unten im View-Teil, wo dann das HTML gerendert wird, da wollen wir wirklich so wenig Logik wie eben möglich haben. Maximal noch irgendwie so ein Array-Durchlauf oder sowas, aber die ganzen Filter für Listen oder On-Click-Händler oder sonstige Sachen, die wollen wir alle oben im Controller-Teil haben. Das ist jetzt nicht MVC im klassischen Sinne, aber eben auch diese optische Trennung schon zwischen den drei Bausteinen. Und das führt dazu, dass wenn man so eine React-Komponente aufmacht, dass sie alle gleich aussehen und alle gleich funktionieren

und man sich sofort wiedererkennt. Genau, und vor allem gerade in der View unten eben wirklich nur die Daten anzeigt. Das ist so auch ein PR-Kommentar, so ein klassischer PR-Kommentar, den wir bei neuen Entwicklern und Entwicklerinnen oft haben, dass unten zum Beispiel diese On-Click-Händler, dass dann da direkt eine Funktion in der View drin ist oder dass irgendwelche Daten doch nochmal gerade ausgerechnet, zusammengerechnet und so weiter werden. Das würden wir dann kommentieren und hätten wir lieber in der mittleren Sektion, wo dann die Daten verarbeitet werden, vorverarbeitet werden und unten dann letztlich nur auch angezeichnet, eingesetzt werden.

Genau, also das ist das MVC-Modell dann ein bisschen extrapoliert und angepasst auf andere Teile der Entwicklung, wo es vielleicht nicht so offensichtlich ist. Super, Kay. Von meiner Seite aus haben wir das schon ganz gut erklärt, was wir mit dem MVC machen und wie wir es verwenden. Hast du noch Ergänzungen? Ansonsten würde ich in den Feedback-Blog springen. Nee, mach das gerne. Ich fühle mich auch gut abgeholt. Ich hoffe, mit unserem etwas besonderen Take haben wir die ganzen Puristen jetzt nicht auf die Barrikaden gebracht. Aber so zumindest ist das ein Ansatz, der sich bei mir in der Realität schon sehr oft als nützlich

und zielführend erwiesen hat beim Entwickeln von auch kleinen Komponenten. Ja, wir freuen uns natürlich total über Feedback und das erreicht uns immer mehr auf verschiedenen Kanälen, worüber ich mich sehr freue. Wahrscheinlich machen wir auch nochmal eine kleine separate Folge, bei denen wir auf Sachen eingehen, die jetzt nicht so richtig in die einzelnen Folgen reinpassen. Eine Sache möchte ich aber hier nochmal gerade mitnehmen. Da habe ich nämlich von einem Freund bei einem Bierchen die Info bekommen. Der ist jetzt kein Informatiker, das muss man dazu sagen, kein Programmierer. Und der sagte, wie schon mehrere vorher tatsächlich auch,

dass unser Podcast-Logo, da steht ja Web-Entwicklung und Unternehmenskultur. Und da steht eben nicht ein Und, sondern da steht ein Doppel-Und. Die Programmierer unter euch, die werden natürlich jetzt wissen, dass das extra so ist und dass das kein Typo ist. Und das möchte ich hier nochmal einmal sagen für alle, die mit Entwicklung noch nicht so viel zu tun hatten. Dieses Und-Und ist also ein kleiner Gag und soll alle Programmierer unter euch abholen. Wobei man halt schon sagen muss, dass wir innerhalb der Folgen relativ monothematisch sind. Da ist dann also eher eine Oder-Verknüpfung. Das stimmt allerdings.

Wir versuchen aber weiter, das so ein bisschen zu verweben. Dann habe ich noch einen kleineren Hinweis in eigener Sache. Und zwar haben wir unsere Website noch erweitert. Und auf unserer Website findet ihr jetzt auch einen Blog über unseren Podcast. Da bin ich ganz stolz drauf. Also für die Leute, die das jetzt hier natürlich hören, die kennen den Podcast ja schon. Ja, vielleicht ist ja der eine oder andere über unsere Website jetzt auf diese Folge gekommen und freut sich, dass es abgeholt wurde. Oder er lernt über diese Folge hier die neue Webseite kennen, die wir uns ja auch sehr schön gebastelt haben, muss ich ja mal sagen.

Gut gebaut, Felix. Das stimmt. Die habe ich übrigens komplett selbst gemacht, ohne mich jetzt selbst loben zu wollen. Aber einfach, damit ihr so einen Eindruck davon bekommt, dass ich auch noch was an der Tastatur kann. Da ist Feedback gerne willkommen. Und ich denke, damit schließen wir die Folge auch. Ja, mein Tee ist leer. Ich freue mich auf die nächste Woche mit dir. Ich freue mich auch, Felix. Bis dahin. Ich freue mich auf die nächste Woche.

Ich freue mich auf die nächste Woche.