Sollte ich auf POST-Parameter im Modell zugreifen oder als Methode Argumente vom Controller übergeben?

Question

Ich muss ungefähr 20 POST-Parameter verarbeiten, und ich bin nicht sicher, wo das zu tun ist.

Ich könnte jedes als ein Argument der Methode auf dem Modell definieren und sie vom Controller übergeben, wenn die Methode aufgerufen wird. Dies würde zu einer Menge Arbeit führen und den Funktionsaufruf aufgrund der Anzahl der Argumente weniger lesbar machen.

Oder ich könnte die Methode auf dem Modell aufrufen, und nur direkt auf die Parameter zugreifen.

Die Übergabe der Parameter als Argumente würde mir mehr Kontrolle darüber geben, auf welche Parameter die Funktion zugreift, und die Dokumentation wäre selbsterklärender. Wenn später jedoch neue Parameter hinzugefügt wurden, müssten sie am Ende des Methodenaufrufs hinzugefügt werden, um nicht jeden vorhandenen Aufruf zu unterbrechen. Ich stelle mir vor, dass dies ziemlich verwirrend werden würde, wenn es ein paar Mal passiert, da die Argumente nicht logisch gruppiert werden können.

Wenn ich auf den Parameter im Modell zugreife, müssen keine Parameter vom Controller an das Modell übergeben werden, wodurch die Methode terser aufgerufen wird. Aber ich habe keine Kontrolle über die Parameter, auf die zugegriffen wird, da sie einfach und ohne Einschränkungen hinzugefügt oder entfernt werden können. Dies würde von den anderen Entwicklern eine größere Disziplin erfordern, und ich möchte mich nicht darauf verlassen, denn früher oder später ist jemand verpflichtet, "einfach (fügen | ändern | fixieren) das wirklich schnell".

Ich bin nicht sicher, welcher Weg zu gehen. Ich tendiere dazu, einfach alles im Modell zu machen, da es schneller zu schreiben ist, einfacher zu warten scheint (kein Argument Chaos) und konzeptionell besser in meine Sicht auf ein Modell passt. Auf der anderen Seite bin ich nicht sicher, ob meine Ansicht eines Modells korrekt ist, und ob es im Chaos endet, wenn ich auf die anderen Entwickler angewiesen bin, die Dokumentation nach jeder Änderung immer zu aktualisieren.

Also, was soll ich tun?

Answer 1

Nun, warum können Sie nicht einfach ein (assoziatives) Array als Parameter in dieser Methode des Modells akzeptieren und dann das ganze $ _POST-Array übergeben? Zumindest meiner Meinung nach würde es die Kapselung nicht brechen.

EDIT: Und wenn Sie nicht gerne assoziative Arrays dafür verwenden, können Sie auch sogenannte "Plain Old Objects" (Objekte, die nur zum tragen von Daten, wie Strukturen in C) verwendet werden. Zum Beispiel, wenn dies eine eingereichten Anmeldung beteiligt zu speichern:

class UserData 
{ 
    protected $name; 
    protected $username; 
    protected $password; 

    public function getName() { /* <...> */ } 
    public function setName() { /* <...> */ } 
    /* other accessors go here */ 
} 

class UserController extends Controller 
{ 
    public function register() 
    { 
     $userData = UserData::create() 
      ->setName($_POST['name']) 
      ->setUsername($_POST['username']) 
      ->setPassword($_POST['password']); 
     Users::add($userData); 
    } 
} 

Dies würde ermöglicht es Ihnen strikte Typisierung in Benutzern verwenden :: hinzufügen und auch den Prozess der Dokumentation zu erleichtern.

Answer 2

Ich antwortete vor einer Weile a similar question. Imho solltest du sie z. wie bereits als assoziatives Array vorgeschlagen (und alle Sicherheitsüberprüfungen vorher vornehmen). Auf diese Weise können Sie Ihre Klassen problemlos wiederverwenden.

Answer 3

Controller. Weil Anfragedaten und Modellmanipulation nicht das Gleiche sind. Das Anfordern von datenbasierter Logik im Modell wird somit für alle anderen möglichen Anforderungen benötigt, und das ist schlecht.

Answer 4

Ich habe mit dem gleichen Problem gekämpft, und die Lösung, die ich gefunden habe, ist flexibel, hält meinen Code wiederverwendbar und ist tolerant gegenüber Änderungen am Frontend: Ich mag es, Setter zu verwenden. Natürlich ist, so Gruppierungsdaten in logischen Möglichkeiten, wie ein Schmerz für jeden einzelnen Wert einen Setter mit helfen:

 
$user = new User(); 
$user->setName($_POST['lastName'],$_POST['firstName']); 
$user->setAddress($_POST['address1'],$_POST['address2'],$_POST['city'],$_POST['state'],$_POST['zip']); 

Sie erhalten den Punkt.Nach dem Speichern in Objektvariablen können Sie diese Werte in allen Methoden Ihres Objekts verwenden.

Erstellen der Modelle auf superglobals angewiesen ist so unflexibel. Es macht auch Unit-Tests zu einem Schmerz.

Answer 5

Hier ist, was ich tue ...

//Object Oriented POST Replacement 
    if ($_SERVER['REQUEST_METHOD'] == 'POST') 
    { 
     $_POST = json_decode(file_get_contents('php://input')); 
    } 

ich meist APIs ich schreibe, die Informationen über JSON mit dem Content-Type: application/json übertragen. Allerdings wird dies funktionieren (und meiner Meinung nach besser), egal wie $_POST wird gefüllt.

Was auch immer es ist, dass Sie tun, schlage ich vor, Drehen des $_POST super-global in ein Objekt. Akzeptieren Sie in Ihren Modellen ein einzelnes Objekt als Argument und ziehen Sie Eigenschaften oder Untereigenschaften ab.

Von dort, setzen Sie einfach Ihre Controller-Methoden bis zum Aufruf der Modell-Methoden mit Ihrem objektorientierten $_POST super-global als einziges Argument.