Ankündigung

Einklappen
Keine Ankündigung bisher.

Verständisfrage zum MVC Pattern

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Verständisfrage zum MVC Pattern

    Hallo PHPler,


    ich habe da mal eine Frage entsprechend dem MVC. Ich habe nun da und dort gelesen und bin nun mittlerweile durcheinander gekommen.


    Meine Frage bezieht sich eigentlich nur darauf ob ich das auch wirklich richtig verstanden habe.


    Im Prinzip kann man das MVC doch eigentlich mit dem EVA Prinzip vergleichen.


    Das heißt M steht für Eingabe, C steht für Verarbeitung und V für Ausgabe.


    Das wiederum heißt, dass Model sorgt eigentlich nur für den Datentransport (Datenbeschaffung und Datenspeicherung von oder in ein Dateisystem oder DB). Das sollte es ja dann für alles gewesen sein was das Model macht.


    Dann kommt man ja schon zum Controler, der nimmt die Daten aus dem Model auf und da werden diese Daten dann validiert und geprüft. Mehr macht der Controler nicht richtig?


    Dann kommt der View, der ist für die Ausgabe der Daten aus dem Model zuständig.


    Da kommt aber nun das Problem was ich habe, bekommt der View die aufbereiteten und geprüften Daten aus dem Controler und gibt diese dann aus oder wie? Im View lädt man ja auch das HTML Template?


    Bin für jede Antwort dankbar die mir ein wenig Licht ins dunkel bringt.


    Vielen Dank euch allen Mit freundlichen Grüßen litter
    Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
    http://www.lit-web.de


  • #2
    Disclaimer: Alles so wie ich es verstanden habe.

    Zunächst mal - was ich am Anfang auch noch nicht ganz begriffen hatte - MVC ist selbst ein Pattern der Präsentationsschicht der Anwendung. Der Controller bildet also mitnichten eine Programmlogik ab, sondern nur die Logik der „Anzeige“. Eine OO-basierte Implementierung eines Affenforms ist IMHO ein gutes Anschauungsbeispiel. Je nach Status wird ja ein Formular, ein Form mit Fehlermeldung oder eine Bestätigungmeldung/Fehlermeldung der Aktion angezeigt. Diese Anzeige könnte bspw. die View darstellen. Was die View hier aktiv macht, wäre bspw. das Form wiederzubefüllen, alle Fehlermeldungen die sie bekommt als Liste darzustellen o.ä.
    Das Model wäre das objektinterne Management für bereits eingegebene Daten, evtl. auch aktuelle Fehlermeldungen o.ä.
    Der Controller würde Requestdaten an das Model übergeben (wo sie verarbeitet und ggf. gespeichert werden). Anschließend könnte er den Status abfragen und eine passende View erzeugen (die View erhält dabei das Model als Arbeitsgrundlage).

    Schlußendlich wird über den Controller die aktuelle View geholt und diese dann dargestellt (Methodenaufruf an View-Objekt).


    Im eigentlichen MVC-Pattern reagiert die View noch auf Nutzer-Interaktion, da diese aber im Client-Server-Bereich immer mit einem Request (und damit Neuerzeugen der gesamten Objektlandschaft) verbunden ist, kann man das vermutlich besser über den Controller abwickeln.
    --

    „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
    Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


    --

    Kommentar


    • #3
      Hallo,

      bitte verwechsle das MVC nicht mit einer Dreischichten-Architektur. Das MVC ist ein Pattern Der Präsentationsschicht und realisiert mit dem Model die Anbindung an die Domänenschicht (Business-Logik). Das MVC stellt ein Dreieck dar, in dem die Views die Aufgabe haben, das Model darzustellen, nicht selten aber auch für die Annahme der Eingabe zuständig sind. Der Controller ist für das „Routing“ der Eingaben zuständig, aktiviert also praktisch das Model bzw. weist Model und View zu. In PHP nimmt der Controller aber meist direkt die Daten an, umgeht die Views also.
      Es gibt jedoch verschiedene Implementierungen und Interpretationen des Patterns und besonders da HTTP ein statusloses Protokoll ist, sieht das Pattern in PHP oft verschieden aus und weicht vom ursprünglichen MVC ab. Oft wird die Business-Logik auch in den Controller gelagert und das Model ist nur noch für die Persistenz zuständig, aber ich sehe diese eher im Model.

      Beitrag editiert:
      […] Zu langsam.
      Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

      Kommentar


      • #4
        Wurde nicht schon oft genug über MVC gesprochen und gibt es nicht genug Tutorials dazu?

        Mit dem EVA Prinzip kannst du das nicht vergleichen. Eingabe ist nicht gleich Datenhaltung (Model). Das Model erzeugt z.b. keine Formulare oder nimmt deren Eingaben entgegen. Das Model ist für die Datenhaltung zuständig und kann nicht nur mit der DB kommunizieren sondern auch aus ganz anderen Elementen bestehen (Textdateien (ini,xml,plain), Emails, Webservices und so weiter).

        Der Controller übergibt die Daten dem View im Regelfall. Der View ist im Endeffekt das HTML Template. Wenn dus genauer wissen willst such doch lieber ein bissl, es gibt genug Themen dazu.

        Kommentar


        • #5
          Zitat von Flor1an Beitrag anzeigen
          Wurde nicht schon oft genug über MVC gesprochen und gibt es nicht genug Tutorials dazu?

          Mit dem EVA Prinzip kannst du das nicht vergleichen. Eingabe ist nicht gleich Datenhaltung (Model). Das Model erzeugt z.b. keine Formulare oder nimmt deren Eingaben entgegen. Das Model ist für die Datenhaltung zuständig und kann nicht nur mit der DB kommunizieren sondern auch aus ganz anderen Elementen bestehen (Textdateien (ini,xml,plain), Emails, Webservices und so weiter).

          Der Controller übergibt die Daten dem View im Regelfall. Der View ist im Endeffekt das HTML Template. Wenn dus genauer wissen willst such doch lieber ein bissl, es gibt genug Themen dazu.
          Genau weil ich ja schon viel gesucht habe und gelesen habe (das habe ich im Ausgangspost ja geschrieben) bin ich ja so verwirrt, weil mal liest man so und dann liest man wieder so. Und genau deshalb habe ich die Frage hier gestellt. Meine Frage war ja nicht kann mir einer mal genau erklären oder so, nein sondern ich wollte nur fragen ob ich das richtig verstanden habe von dem her was ich so gelesen habe. Und die Antworten sagen mir nun ganz klar, ich war auf dem Holzweg.

          Manko schrieb schon ganz gut es wird mal so und mal so interpretiert und naja das hat mich eben sehr verwirrt. Nun stehe ich wieder am Anfang und muss weiter rein büffeln bis das in meine Birne rein geht.
          Aus dem Dynamo Lande kommen wir. Trinken immer reichlich kühles Bier. Und dann sind wir alle voll, die Stimmung ist so toll. Aus dem Dynamo Lande kommen wir.
          http://www.lit-web.de

          Kommentar


          • #6
            Frage einen langjährigen PHP-Programmierer und frage einen Studenten, der frisch von der Uni kommt und keine Welt jenseits von Java kennt. Du wirst zwei vollkommen unterschiedliche Antworten erhalten. Letztendlich ist das MVC-Pattern einmal für Smalltalk entworfen und seitdem auf viele Sprachen portiert worden, wobei jede andere Anforderungen stellt, andere Möglichkeiten bietet. Somit ist MVC mittlerweile zu einem Begriff geworden, der eine Vielzahl verschiedener Patterns abdeckt, die alle zwar in Grundzügen ähnlich, aber doch oft sehr verschieden sind. Wie ich es umsetzen würde, habe ich geschrieben. Ich kenne aber auch jede Menge Anwendungen, die es ganz anders interpretieren.
            Letztendlich sehe ich den Sinn des MVCs aber auch nicht darin, eine starre Struktur zu erstellen. Es soll dir helfen, deine Anwendung besser zu gliedern und Komponenten wiederverwendbar zu machen. Ob deine Implementierung nun faktisch ein korrektes MVC ist, spielt da eher die zweite Geige. Das sage ich bewusst so, auch wenn viele Leute gern die Never Ending Discussion über „das“ korrekte MVC führen.
            Refining Linux: “Performing Push Backups – Part 1: rdiff-backup

            Kommentar


            • #7
              Ein Controller sollte etwa so aussehen:
              PHP-Code:
              <?php
              class NewsController {
                public function 
              editAction() {
                  
              $manager $this->_getManager("NEWS");
                  
              $news $manager->getNews($this->_request->getPost("id"0));
                  
              $form = new News_Form_Edit($news);
                  
              $params $this->_request->getPost();
                  if (
              $form->isValid($params)) {
                    
              $news $form->getNews();
                    
              $manager->save($news);
                  } else if (
              $this->_isPostRequest()) {
                    
              $form->populate($params);
                  }
                  
              $this->view->form $form;
                  
              $this->view->render("news/edit.tpl");
                }
              }
              ?>
              Sehr kurz, wenig Quellcode, einfache Verteilung der Parameter auf die entsprechenden Klassen (Modelle) in denen du dann deine eigentliche Geschäftslogik abbildest. Der Controller kennt dein Formular nicht im Detail, er weiß, dass es das Formular gibt und dass er es hierfür mit Daten zu füttern hat. Das reicht, das ganze nennt sich Skinny-Controller/Fat-Model.

              Der Grund liegt auf der Hand, Controller sind üblicherweise anwendungsspezifisch, Models hoffentlich nicht ausschließlich. Da anwendungsspezifische Skripte eben für jede Anwendung neu geschrieben werden, solltest du den Programmieraufwand dafür gering halten. Ein News-Formular ist nicht zwingend anwendungsspezifisch, du könntest die News-Klasse mit Titel, Teaser, Text und Bildupload für ein anderes Projekt einfach wiederverwenden. Wenn du nun die Validierung in den Controller verlagert hättest, müsstest du das ganze fürs nächste Projekt erneut schreiben (oder Copy/Paste benutzen, was man sicherlich vermeiden möchte).

              Der View bekommt dann das Formularobjekt und kann es entweder (wie beim Zend) ganz rudimentär mit dem Standard-Decorator ausgeben (alle Elemente durchlaufen und z.B. tabellarisch anzeigen) oder gezielt auf die Elemente zugreifen und sie darstellen, z.B. um spezielle Anforderungen an die Darstellung zu erfüllen.
              "Mein Name ist Lohse, ich kaufe hier ein."

              Kommentar


              • #8
                @Criz, dein kleines Beispiel erklärt mehr, als duzende Verweise auf das APF und (nicht übertrieben) hunderte von gegoogleten Seiten, die angeblich das MVC erklären.

                Kommentar


                • #9
                  Aber diese Beispiele findest du zu Hauf im Netz! Schau dir doch mal die Beispielanwendungen der ganzen MVC Frameworks an ... dort haste in jedem Beispiel so nen Controller, dazu muss doch nicht extra hier jemand nochmal den Code posten.

                  Kommentar


                  • #10
                    Flor1an, mag sein. Aber als unerfahrener User versuchst du in erster Linie _nachzuvollziehen_ und bis du dann bei so einem Beispiel angekommen bist, musst du dich durch ewige Zeilen Code und zig Vererbungen durchkämpfen.

                    Ich will ganz ehrlich sein, das APF von Dr. E. mag zwar ein gutes sauberes Tool sein, dass bestimmt auch des Lobes würdig ist. Aber für einen Anfänger ist es viel zu viel Code auf einmal und wenn man eine (für Fortgeschrittene banale) Frage hat, dann immer wieder auf das APF verwiesen zu werden kann zuweilen sehr frustrierend sein. Das kann man doch als Anfänger nicht nachvollziehen, auch wenn man es mit viel Zeit und Mühe durchstudiert.

                    Kanns ja verstehen, wenn man es irgendwann leid ist als Moderator. Aber für uns Anfänger ist das schwierigste das richtige Beispiel zu finden, welches uns nämlich das Muster im Kopf klarer darstellt.

                    Kommentar


                    • #11
                      Bei der Einführung des Zend Frameworks hast du z.B. folgenden Controller als Beispiel:

                      PHP-Code:
                            // application/controllers/GuestbookController.php
                            
                      class GuestbookController extends Zend_Controller_Action

                            
                      {
                                
                      // snipping indexAction()...

                                
                      public function signAction()
                                {
                                    
                      $request $this->getRequest();
                                    
                      $form    = new Application_Form_Guestbook();
                             
                                    if (
                      $this->getRequest()->isPost()) {
                                        if (
                      $form->isValid($request->getPost())) {
                                            
                      $comment = new Application_Model_Guestbook($form->getValues());
                                            
                      $mapper  = new Application_Model_GuestbookMapper();
                                            
                      $mapper->save($comment);
                                            return 
                      $this->_helper->redirector('index');
                                        }
                                    }

                                    
                      $this->view->form $form;
                                }
                            } 
                      Das hätte doch auch ausgereicht oder nicht? Man muss nur bissl suchen dann findet man solche Beispiele schon.

                      Kommentar


                      • #12
                        Na ist ja egal, ob oder wann man es findet, relevant ist, dass der Controller die Models konfiguriert und möglichst einfach gestrickt sein sollte.
                        "Mein Name ist Lohse, ich kaufe hier ein."

                        Kommentar


                        • #13
                          Hallo nuna,

                          nachdem ich schon angesprochen wurde, möchte ich wenigstens die Chance haben, auch etwas zum Thread beizutragen.

                          Grundsätzlich ist das MVC-Pattern eines der bekanntesten und auch eines der am häufigsten falsch interpretierten Pattern. Wie Chriz schon angedeutet hat, gibt es auch unterschiedliche gültige Interpretationen des Pattern und damit verbunden natürlich differierende Implementierungen. Vor- sowie Nachteile haben sie alle, nur ist es bei einem Pattern in der Natur der Sache, dass es durch einen Scope an einen oder weniger Anwendungsfälle gebunden ist. Grob gesprochen gibt es folgende Ansätze, basierend auf dem MVC-Pattern:
                          • Plain MVC - der View enthält die komplette Logik zur Darstellung des Models
                          • Fat controller - der Controller übernimmt den Großteil der Ausgabe-Logik und Steuerung (z.B. Vor-Befüllung eines Formulars, ...)
                          • Fat model - das Model übernimmt den Großteil der Datenverwaltung (etwa die Implementierung des Active-Record-Pattern)
                          • View Model - das Model wird zu einem "Daten-Halter" für den Zustand einer Applikation und rückt hinsichtlich der Datenverwaltung gegenüber dem Controller in den Hintergrund
                          • Integration in eine 3-tier-architecture - hier wird das MVC-Pattern zu einem Pattern der Präsentations-Schicht und lässt sich durch Business-Services hinsichlich Datenverwaltung und Applikationssteuerung "helfen". Hier kommt oft das Pattern Front-Controller zum Einsatz
                          • HMVC - hier wird ein Baum / Kaskade von MVC-Elementen aufgebaut um die Applikation besser strukturieren und hinsichtlich Wiederverwendung besser auslegen kann. Das Model wird hier oft zu einem von mehreren (M)VC-Elementen gemeinsam genutztes Objekt (z.B. alle Views eines Gästebuchs nutzen ein Model).

                          Zu diesen Themen habe ich bereits einige Artikel für das PHP-Journal geschrieben. Der IMHO für die Integration der Pattern relevante Artikel ist Objektorientiertes Design eines Gästebuchs. Dieser beschreibt ein Gästebuch aus OO-Sicht zunächst aus einer APF-neutralen Position und hilft dir vielleicht zur Einordnung der oben genannten Spielweisen etwas.

                          Aber für einen Anfänger ist es viel zu viel Code auf einmal und wenn man eine (für Fortgeschrittene banale) Frage hat, dann immer wieder auf das APF verwiesen zu werden kann zuweilen sehr frustrierend sein. Das kann man doch als Anfänger nicht nachvollziehen, auch wenn man es mit viel Zeit und Mühe durchstudiert.
                          Für einen blutigen Anfänger, der gerade ein paar PHP-Schritte gehen kann, bietet ein Framework im Allgemeinen ein zu hohen Einstiegs-Punkt. Das gilt gleichermaßen für alle PHP-Frameworks - auch wenn immer das Gegenteil behauptet wird. Weiterhin sollte ein PHP-Anfänger auch kein MVC implementieren, denn auch das ist IMHO schon etwas für Fortgeschrittene. Wenn du als Anfänger sauberen Code schreiben möchtest - und ich finde es schön, dass du diesen Anspruch hast -, dann braucht es dazu keine Pattern und auch keine Frameworks. Es reicht, deinen Code sauber zu strukturieren, sprich die unterschiedlichen Aufgaben sauber zu trennen und wiederverwendbar auszulegen. Sofern es Code von Layout zu trennen gilt, reichen Smarty & Co. und ein gut sortierter PHP-Code völlig aus.
                          Solltest du mit PHP soweit sicher sein und auch schon einige Projekte hinter dir liegen, in denen man sich immer wieder fragt, ob das entwickelte nicht doch besser wiederverwendet werden könnte ist es Zeit, sich um die Auswahl der Tools zu kümmern, die einen auf etwas höherer Ebene unterstützen Code zu strukturieren, Wiederverwendung zu schaffen und bereits gewisse Aufgaben durch die Implementierung von Best-Practice-Lösungen abnehmen. Ab diesem Zeitpunkt macht es Sinn, sich auch mit dem Thema Frameworks zu beschäftigen, was allerdings vorraussetzt, dass man sich im Entwickler-Umfeld sicher fühlt, fremden Code wirklich lesen und verstehen kann, sowie API-Dokumentationen überreissen kann. Man muss nicht MVC implementieren, weil es alle toll finden. Ich beispielsweise finde MVC absolut unbrauchbar, wenn es nicht durch Tools unterstützt wird und durch ein "H" zu Beginn des Pattern-Namen erweitert wird (siehe vielleicht hier auch den oben verlinkten Artikel).

                          So, nun habe ich einige Zeilen über das MVC-Pattern und Pattern im Allgemeinen verloren, lass uns ein wenig konkret werden:

                          Aber als unerfahrener User versuchst du in erster Linie _nachzuvollziehen_ [..]
                          Als Anfänger und Unerfahrener ist es immer zunächst schwer die teilweise sehr komplexen Konzepte wirklich nachvollziehen zu können. Das liegt nicht daran, dass man zu unintelligent ist oder keiner Lust hat, einem das zu erklären. Es mag daher im Forum immer wieder den Anschein haben, dass das der Fall ist, aber das trifft für mich nicht zu. Ich habe oft etwas wenig Zeit für die Beantwortung der Frage und werfe zwei Sätze in die Diskussion sein, die exakt zutreffen. Ich habe es nicht allzuwenig erlebt, dass dann auf Seite 4 der Satz "Schau mal auf Seite 1!" steht. Es wird natürlich ebenso vom TE eine gewisse Selbst-Disziplin gefordert die genannten Begriffe und Zusammenhänge zu selbst hinterfragen.
                          Das alles sehe ich bei dir gegeben - und deswegen antworte ich auch so ausführlich -, nur kannst du trotzdem nicht von dir verlangen, alles von Anfang an nachvollziehen und verstehen zu können. Manche Feinheiten lernt man erst beim exzessiven Gebrauch eines Tools und das ist IMHO auch ok so. Warum sollst du das komplette Konzept des APF verstehen, wenn du nur eine kleine Webseite bauen möchtest. Sicher ist das der Wunsch eines jeden Entwicklers aber es wird dir sicher nicht bei allen Dingen gelingen - zu mindest, wenn du fremden Code verwendest. Das geht selbst mir immer noch so! Es ist nur wichtig, dass du dich in deinem Bereich sicher fühlst. Das Verständnis kommt dann entweder aus der Anwendung selbst oder duch Diskussion der Anwendungsfälle. Aber das setzt voraus, dass man sich zunächst mit wenigen Erfolgen zufrieden gibt und die Anwendung lernt. Insbesondere beim MVC-Pattern ist das IMHO sehr wichtig, ein Tool zu haben, dass einem einen Rahmen der MVC-Implementierung vorgibt. Das mag sich zunächst umständlich anfühlen, erleichtert dir aber die Implementierung.

                          [..] und bis du dann bei so einem Beispiel angekommen bist, musst du dich durch ewige Zeilen Code und zig Vererbungen durchkämpfen.
                          Sofern du das auf das APF beziehst, so kann zur Darstellung eines Formulars mit 100 Elementen bereits der Controller-Code

                          PHP-Code:
                          class foo_controller extends base_controller {
                             public function 
                          transformContent(){
                                
                          $this->__getForm('foo')->transformOnPlace();
                             }

                          ausreichen. Sofern man das Beispiel von Chriz mit der Speicherung der News weiter spielt sieht das im APF so aus:

                          PHP-Code:
                          class news_controller extends base_controller {
                             public function 
                          transformContent(){
                                
                          $form = &$this->__getForm('news');
                                if(
                          $form->isSent() && $form->isValid()){
                                   
                          $title $form->getFormElementByName('title')->getAttribute('value');
                                   
                          $date $form->getFormElementByName('date')->getDate();
                                   
                          $content $form->getFormElementByName('content')->getContent();
                                   
                          $this->getManager('NEWS')->save(new News($title,$date,$content));
                                } else {
                                   
                          $form->transformOnPlace();
                                }
                             }

                          Gemessen an der Anzahl der Zeilen also kein großer Unterschied. Beide Beispiele verschweigen dir natürlich, wie der Manager wirklich bezogen wird. Das ist allerdings auch nicht wichtig für die Diskussion hier. Man kann sich später sicher über Konzepte wie DI etc. unterhalten, aber for now ist das nicht relevant.
                          Zugegeben, in diesem Beispiel spielt Vererbung eine Rolle, das beschränkt sich aber exakt darauf, dass du die Interface-Methode transformContent() statt editAction() implementierst und der base_controller hilft auf das Formular zuzugreifen. Gerade letzteres ist hinsichtlich des Mehraufwands 30 Zeichen mehr tippen zu müssen schon rentabel.
                          Zugegeben, mein Beispiel geht dabei auch nur von der Erzeugung nicht von der Editierung aus. Das würde sich allerdings auch wie folgt abbilden lassen:

                          PHP-Code:
                          class news_controller extends base_controller {
                             public function 
                          transformContent(){
                                
                          $form = &$this->__getForm('news');
                                if(
                          $form->isSent()){
                                   if(
                          $form->isValid()){
                                      
                          $title $form->getFormElementByName('title')->getAttribute('value');
                                      
                          $date $form->getFormElementByName('date')->getDate();
                                      
                          $content $form->getFormElementByName('content')->getContent();
                                      
                          $this->getManager('NEWS')->save(new News($title,$date,$content));
                                   } else {
                                      
                          $form->transformOnPlace();
                                   }
                                } else {
                                   
                          $news $this->getManager('NEWS')->get(RequestHandler::getValue('id',0));
                                   
                          $form->getFormElementByName('title')->setAttribute('value',$news->getTitle());
                                   
                          $form->getFormElementByName('date')->setDate($news->getDate());
                                   
                          $form->getFormElementByName('content')->setContent($news->setContent());
                                   
                          $form->transformOnPlace();
                                }
                             }

                          Es scheint zunächst etwas mehr Schreibarbeit hinsichtlich der Befüllung des Formulars und des Auslesens zu sein, hier ist jedoch bereits die APF-Formular-Abstraktion inkludiert. Diese lässt dich Formulare komplett in einem DOM-Baum abstrahieren. Du definierst diese quasi inkl. Markup in einem Template - musst also keinerlei PHP-Code schreiben -, das Formular steht dir aber trotzdem als Objekt mit den im Template beschriebenen Controls zur Verfügung. Das zugehörige Template könnte also wie folgt aussehen:

                          Code:
                          <html:form name="news" method="post">
                             <label for="title">Titel:</label>
                             <form:text name="title" id="title" />
                          
                             <label for="date">Datum:</label>
                             <form:date name="date" id="date" />
                          
                             <label for="content">Inhalt:</label>
                             <form:area name="content" id="content" />
                          
                             <form:button name="save" value="Speichern"/>
                          </html:form>
                          Sofern du den Inhalt noch vor den Speichern absichern möchtest, kannst du Validatoren und Filter einhängen. Aber auch das ist nicht relevant hier. Die Abstraktion lässt sich sehr schön am Datums-Feld sehen. Hier hast du "auch nur" ein Tag wie beim Titel, es abstrahiert für dich aber schon das komplette Presetting, Ausfüllen, Sichern, ... und du must hinterher nur noch getDate() anfragen. IMHO eine schöne Sache.

                          Wie gezeigt, muss MVC mit dem APF nicht schwer sein, es kann sogar noch deutlich mehr helfen als man zunächst denkt. Auch solltest du dich nicht von Vererbung und etwas mehr Code abschrecken lassen etwas zu verwenden, was dir vielleicht in Zukunft noch mehr helfen kann als du jetzt abzuschätzen vermagst (und das gilt im übrigen jetzt als Tool-unabhängige Aussage!). MVC ist ein OO-Pattern und Vererbung - insbesondere - ist ein Stil-Mittel der OO-Welt. Bitte also nicht davor zurückschrecken, denn sollte dich das wirklich schon verwirren, solltest du vielleicht noch etwas warten, bist du dich mit den Konzepten beschäftigst.

                          So genug APF, denn ich will ja nicht mit zu viel komplexem Code verschrecken.

                          Noch ein persönliches Anliegen: sofern du bei den Verweisen auf das APF etwas nicht verstanden hast, dann frag doch einfach. Sowohl hier als auch im APF-Forum wird dir da definitiv geholfen.
                          Viele Grüße,
                          Dr.E.

                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                          1. Think about software design before you start to write code!
                          2. Discuss and review it together with experts!
                          3. Choose good tools (-> Adventure PHP Framework (APF))!
                          4. Write clean and reusable software only!
                          ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

                          Kommentar


                          • #14
                            @dr.e.

                            Ich danke dir für deine Mühe, mir in einem sehr langen Beitrag zu anworten. Ich fühle mich sehr geehrt und muss sagen, dass mich deine freundliche und geduldige Art stark beeindruckt.

                            Ja, ich war etwas frustriert wegen der eigenartig kühlen Stimmung in den deutschen Foren. Da ich zur Zeit freie Kapazitäten habe, will ich diese intensiv nutzen um Software-Design näher zu studieren. Da bot es sich an, mal auf das MVC-Pattern zu schauen um zu sehen, wie Code moderner und performanter geschrieben werden kann. Es ging mir auch nicht darum, selbst ein Framework auf Basis dieses Patterns aufzusetzen. Nur würde ich schon gerne näher verstehen, bevor ich sie einsetze. Wie oft war ich froh, wenn ich auf gutfrequentierten englischsprachigen Foren landete, weil ich dort nicht das Gefühl vermittelt bekam "boaah, was ne sch.. easy Frage du stellst... hier friss echo 'hello world';"

                            Bei der Aufteilung auf der Arbeit, wer welches Framework studieren sollte, hatte ich vorgeschlagen, auch das APF durchzunehmen. Dr. E., ich bin dir und Programmierern wie dir sehr dankbar, dass ihr uns an eurem Wissen/Können teilhaben lässt. Was ich jedoch sagen will ist, dass einige Zeilen Code bei jemandem, der dem Konstrukt noch fremd ist, mehr verdeutlicht als z. B. deine ausführliche Erklärung des technologie unabhängigen OOP Designs eines Gaestebuchs.

                            Vielleicht wäre es hilfreich, wenn man Skripte (von mir aus einfach kommentarlos) in einen eigenen Bereich unterbringen könnte. Was weiß ich:
                            PHP-Code:
                            -PHP-Einsteiger
                             
                            -- bla
                            -PHP-Fortgeschrittene
                             
                            -- ..
                            -
                            Software-Design
                             
                            -- ...
                            -
                            Datenbanken
                             
                            - ...
                            -
                            Skriptfetzen
                             
                            kleines Login-Skript
                             
                            Popelbeispiel für nen Controller
                             
                            mini-Rechteverwaltungsdingens 

                            Kommentar


                            • #15
                              Wir haben sogar einen kleinen Tutorials-Bereich. Dir muß aber klar sein, dass man nicht alle Dinge mehr "in ein paar Codezeilen" darstellen kann. MVC besteht bspw. aus mehreren Komponenten. Und nicht jedem reicht ein Controller, um bereits das Prinzip zu erkennen. Das ist sehr subjektiv. Zudem - es gibt solche Sachen im Netz. Auch in Deutsch! Ich finde es manchmal etwas fragwürdig, was hier alles so erwartet wird. Es sind hier fast immer die selben User, die lange Beiträge verfassen oder Mehrwerte schaffen (Wiki, Quellensammlungen o.ä.). Doc E. führt dazu noch sein eigenes APF-Forum! Haben-Wollen ist ja schön und gut, aber wo sollen wir denn alle die Zeit hernehmen?

                              PS: Deine "Scriptfetzen" sind bei uns übrigens die Scriptbörse. Leider kommen in den letzten Jahren fast ausschließlich Fragen nach Scripten, keine Angebote.
                              --

                              „Emoticons machen einen Beitrag etwas freundlicher. Deine wirken zwar fachlich richtig sein, aber meist ziemlich uninteressant.
                              Wenn man nur Text sieht, haben viele junge Entwickler keine interesse, diese stumpfen Texte zu lesen.“


                              --

                              Kommentar

                              Lädt...
                              X