Devo accedere ai parametri POST nel modello o passare come argomenti del metodo dal controller?

Question

Devo elaborare circa 20 parametri POST e non sono sicuro di dove farlo.

Potrei definire ciascuno come argomento del metodo sul modello e passarli dal controller quando viene chiamato il metodo. Ciò comporterebbe un bel po 'di lavoro e renderebbe la funzione chiamata meno leggibile, a causa del numero di argomenti.

Oppure potrei chiamare il metodo sul modello e accedere direttamente ai parametri.

Passare i parametri come argomenti mi avrebbe consentito un maggiore controllo sui parametri a cui la funzione accede e la documentazione sarebbe più intuitiva. Ma se i nuovi parametri sono stati aggiunti in seguito, dovrebbero essere aggiunti alla fine della chiamata al metodo, in modo da non interrompere tutte le chiamate esistenti. Immagino che questo diverrebbe abbastanza confuso se dovesse accadere alcune volte, poiché gli argomenti non possono essere raggruppati logicamente.

Se accedo al parametro nel modello, non è necessario passare alcun parametro dal controller al modello, rendendo il metodo chiamato terser. Ma non ho alcun controllo sui parametri a cui si accede, in quanto possono essere aggiunti o rimossi facilmente e senza restrizioni. Ciò richiederebbe una maggiore disciplina da parte degli altri sviluppatori, e non mi piace dipendere da questo, perché prima o poi qualcuno è destinato a "solo (aggiungi | cambia | aggiusta) questo molto veloce".

Non sono sicuro su quale direzione andare. Tendo a fare tutto nel modello, poiché è più veloce da scrivere, sembra più facile da mantenere (nessun argomento caotico) e concettualmente si adatta meglio alla mia visione di un modello. D'altra parte, non sono sicuro che la mia vista di un modello sia corretta, e se finirà nel caos se dipenderò dagli altri sviluppatori per aggiornare sempre la documentazione dopo ogni modifica.

Quindi, cosa dovrei fare?

Answer 1

Bene, perché non si può semplicemente accettare un array (associativo) come parametro in quel metodo del modello e quindi passarlo all'intero array $ _POST? Almeno secondo me, non romperebbe l'incapsulamento.

EDIT: E se non vi piace usando gli array associativi per questo, è anche possibile utilizzare i cosiddetti "Plain Old Objects" (oggetti che vengono utilizzati solo per trasportare i dati, come le strutture in C). Ad esempio, se questo ha comportato il salvataggio di un modulo di registrazione presentata:

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); 
    } 
} 

Ciò consentirebbe di utilizzare la tipizzazione forte in Utenti :: aggiungere e anche rendere il processo di documentazione più facile.

Answer 2

Ho risposto allo a similar question qualche tempo fa. Imho dovresti passarli per es. come già proposto come array associativo (e fare tutti i controlli di sicurezza prima). In questo modo puoi facilmente riutilizzare i tuoi clases.

Answer 3

Controller. Perché i dati delle richieste e la manipolazione del modello non sono la stessa cosa. La richiesta di una logica basata sui dati nel modello sarà quindi richiesta per tutte le altre richieste, e questo è male

Answer 4

Ho lottato con questo stesso problema, e la soluzione che ho trovato è flessibile, mantiene il mio codice riutilizzabile, e è tollerante delle modifiche al front-end: mi piace usare setter. Naturalmente, avere un setter per ogni singolo valore è un dolore, quindi i dati di raggruppamento in modi logici aiuta:

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

Si ottiene il punto.Una volta salvati in variabili oggetto, puoi usare questi valori in tutti i metodi dell'oggetto.

Rendere i tuoi modelli dipendenti da superglobali è così inflessibile. Rende anche il test unitario un dolore.

Answer 5

Ecco quello che faccio ...

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

Sono per lo più a scrivere le API che trasferiscono le informazioni sopra JSON con il Content-Type: application/json. Tuttavia, questo funzionerà (ed è meglio a mio parere), indipendentemente da come viene popolato lo $_POST.

Qualunque cosa tu stia facendo, ti suggerisco di trasformare il super-globale $_POST in un oggetto. Nei tuoi modelli accetta un singolo oggetto come argomento, e tira fuori proprietà o sotto-proprietà.

Da lì, è sufficiente impostare i metodi del controller fino a chiamare i metodi del modello con il proprio Object Oriented $_POST super-globale come unico argomento.