mvc pattern einsatz

Guten Tag allerseits,
anbei eine Frage zum MVC-Pattern. Ich habe mich im Netz über MVC informiert, jedoch entzieht sich der wirkliche Mehrwert sich meinem Geiste. Ich versuche das ganze ohne Code zu formulieren, da ich bisher noch keine großartigen Versuche unternommen habe das Ding zu implementieren, weil es sich auch teilweise in seiner Implementierung im Netz widerspricht:
-Model: Würde bei mir sämtliche Logik enthalten. Auch Datenbank- und Validationslogik.
-View: Schon meine erste Frage: Mit den Views im Netz könnte man diese eine Klasse immer wieder nehmen, und muss nicht von anderen Views ersetzt werden. Operationen: Template laden und mit Methode aufrufbar machen, sonst nicht viel mehr.
-Controller: bekommt View und Model Objekt. Nimmt meiner Meinung nach nur Post daten entgegen und wählt anhand dieser die jeweilige Funktion im Model aus und gibt entsprechend diesen die jeweilige View aus.

Meine Fragen:
Im Hauptprogramm rufe ich somit ja nur

$c = new Controller();
$c->invoke();
$c->displayView(); 

auf. Wäre es nicht sinnvoll, wenn ich auf den Controller verzichten würde und diesen eher prozedural programmieren würde, und auf die Klasse verzichten würde. Also dass dieser prozedurale Controller bereits mein Hauptprogramm ist, sodass ich nur "main", Model und View hab?
Zudem sieht die View ja in allen MVC-Gruppen, die sie verwenden, gleich aus. Hab ich da einfach was falsch gemacht oder hab ich nicht genug Saft in der Birne.
Gerne auch Probleme meiner Darstellungen aufzeigen.
Gruß.

[Ma27]

Hallo phpyton,

vorne weg: das MVC Pattern ist ein Pattern für die Präsentationsschicht.
Eine einfach Implementierung findest du hier: https://github.com/BlackScorp/MVC

-Model: Würde bei mir sämtliche Logik enthalten. Auch Datenbank- und Validationslogik.

Nicht wirklich. Datenbank wäre etwas für die Datenschicht und Validierungsregeln gehören imo in die Businessschicht. Siehe hierzu: http://de.wikipedia.org/wiki/Schicht...en-Architektur

-View: Schon meine erste Frage: Mit den Views im Netz könnte man diese eine Klasse immer wieder nehmen, und muss nicht von anderen Views ersetzt werden. Operationen: Template laden und mit Methode aufrufbar machen, sonst nicht viel mehr.

Stimmt so in etwa. Ich würde einfach eine Template Klasse nutzen und dazu Templates erstellen, aber ich würde dafür vorhandene Biliotheken, wie Twig (http://twig.sensiolabs.org/) oder Mustache (https://github.com/bobthecow/mustache.php/) nutzen.

-Controller: bekommt View und Model Objekt. Nimmt meiner Meinung nach nur Post daten entgegen und wählt anhand dieser die jeweilige Funktion im Model aus und gibt entsprechend diesen die jeweilige View aus.

Und wieso nur Post Daten? Gibt ja auch GET Formulare (bestes Beispiel ist da Google)
Ich würde dem Controller ein Request Objekt übergeben, das du im Frontcontroller oder so mit

Request::createFromGlobals() 

oder etwas in der Richtung erstellst.
Dafür könntest du so etwas nutzen. https://github.com/symfony/HttpFoundation
Dan könntest du dem Controller ein Request Objekt übergeben, dieser führt irgendwelche Aktionen aus und erstellt eine Response. Die Response muss nur noch via

$response->send(); 

gesendet werden.

Ich hoffe das hilft etwas,
Ma27

[Phpyton]

Erstmal danke für die Antwort.

Validierungsregeln gehören imo in die Businessschicht

Damit dachte ich eher an Validierungen, die Klassenattirube validieren sollen. Z.B. eine Klasse Mensch prüft intern ob das Geschlecht männlich oder weiblich ist.

Datenbank wäre etwas für die Datenschicht

Ich habe aber etwas zum Thema Big Models gelesen, wo man alles zusammenfasst. Bsp: Nach der Prüfung des Geschlechts wird bei Erfolg das Geschlecht in die Datenbank eingetragen. Somit würde Validierung und Datenbankeintrag zusammenhängen. Ich sehe im ersten Augenblick keinen Sinn eine eigene Schicht dafür zu machen, ausser das Model zu schmälern

[BlackScorp]

Hallo Phpython,

validierung ist ein eigenes Thema, es kann in dem Controller validiert werden, im Model selbst und später im View bei der ausgabe. ein generell muss es da validiert werden, gibt es sowieso nicht und es ist vom Usecase abhängig.

Da du dich aber in MVC gerade einarbeitest, kann ich dich vielleicht von einem anderem Konstrukt überzeugen.

Es hat viele namen und unterscheidet sich nur geringfügig, man nennt es Clean Code Architecture oder Data Context Interaction oder Onion Architecture.

Die herangehensweise an ein Problem ist anders als bei MVC, wenn du ein feature in deine software einbauen willst, überlegst du nicht, was M was V was C sein soll. Du erstellst einfach 3 klassen , Request, Response, Interaktion und das bei JEDEM feature.

zb AccountCreateRequest, AccountCreateResponse, AccountCreateInteractor
oder LoginRequest LoginResponse LoginInteractor

ganz straight forward bei jedem feature 3 klassen. Die Interactoren haben dann eine methode , zb execute, process, run what ever und diese Method erwartet als Parameter den Request und Response und zwar immer.

Somit hast du schon mal sofort eine vorstellung wie du deine features definieren kannst.

das ganze funktioniert dann sowohl mit MVC als auch ohne MVC. und ohne MVC wird es sogar ziemlich verständlich.

nimm zb diese 58 zeilen code
https://github.com/BlackScorp/logd/b...ate.php#L1-L58

in der ersten zeile wird einfach nur die hauptphp eingebunden, diese nutzt autoloader und packt eigene dinge wie zb datenbank verbindung in einen DI container.

dann sammle ich die werte aus den $_POST variablen, übergebe die an meine Request klasse und führe meine execute methode des interactors aus.

am ende habe ich dann ein Response welcher einfach mit dem Template vermischt wird und ausgegeben wird.

was hast du nun davon, wenn du das so umsetzt?
1) du kannst deine features simulieren und gucken was rauskommt ohne jetzt auf der webseite irgendwo rumklicken zu müssen, viel besser sogar, du kannst verschiedene szenarien automatisiert testen
https://github.com/BlackScorp/logd/b...CreateTest.php

wenn du irgendwas später an der logik veränderst und irgendwie was ausversehen veränderst, siehste fehler noch befor du deine seite live schaltest, es erspart dir viel dbugging zeit

2) angenommen ich möchte meine Registrierung über eine externe api aufrufen oder einem externen client programm(etwa eine app) ich bräuchte da ledeglich mein Response Objekt im JSON format ausgeben und fertig

3) MVC Frameworks sind sehr gut kompatibel mit der architektur
https://github.com/Opentribes/Core/b...er/Account.php
hier zb mein Controller der Interactoren aufruft

weil das Problem ist ja aktuell, MVC wurde allgemein definiert für Smalltalk und dort wurde es in kleinen kontexten benutzt, etwa ein input feld hatte ein Model, eine klasse mit eigenschaft value , ein View , eine klasse mit eigenschaften wie border color usw und controller der mit events das view oder model verändert hat. sowas kannst du nicht einfach so in PHP Umsetzen.
Weil bei jedem request der alte zustand wiederhergestellt werden muss.

Viele Frameworks haben dann MVC ansätze umgesetzt, im Kern sind diese gleich, nach außen sind die Teilweise je nach framework unterschiedlich. und je nach framework wirste die sachen anders angehen. mit der Lösung von mir hast du einen Ansatz generell für alles. Ich habe es sogar bei legacy code angewandt, neue features in vorhandenen code einzubauen und dabei die klassen aus dem legacy code zu benutzen ist dann wirklich nur noch ein klax

schon wieder so viel geschrieben.. muss mal ein Blog Artikel darüber verfassen und immer wieder mal hier drauf verlinken