Devo mantenere i metodi "reindirizza solo" nel mio Controller?

1

Controller:

function indexAction()
{
    if ($condition)
        $this->renumPosition($id);    //LINE #1
}

//Redirect only - function's sole purpose is to call another function
function renumPosition($id)
{
    $this->repository->renumPosition($id);
}

Repository:

function renumPosition($id)
{
    //SQL, DQL, ORM code follows
    ...
}

Domanda

Se la riga n. 1 (sopra) deve essere

$this->repository->renumPosition($id);

e dovresti rimuovere renumPosition dal controller?

La domanda è ... quando rinvio dell'esecuzione direttamente al mio modello / livello repository, e quando chiamo una funzione di un controller che rimanda al livello modello / repository?

Questa è forse una domanda davvero sottile. Solo per notare, il mio intento qui NON è quello di salvare una chiamata di funzione in più, ma di allinearmi con una filosofia di programmazione.

Ad esempio, posso argomentare che quando Controller deve essere consapevole di un'azione, dovrei avere un pubblico method in Controller che può effettuare una chiamata a repository . Ma poi, quando è un'azione interna , forse posso richiamare il repository direttamente senza effettuare una chiamata al metodo separata in Controller.

Ha senso?

Qual è il mio obiettivo / preoccupazione

Ecco il codice legacy che ho iniziato con:

Controller:

function indexAction()
{
    if ($condition)
        $this->renumPosition($id);    //LINE #1
}

function renumPosition($id)
{
    //Heavy SQL, DQL, ORM code follows - say 50-70 lines
    ...

    $db->db_function($sql)

    ...

    $db->db_function($moreSql)

    //some more code here that relates to DB transactions
    $db->db_function($moreSql)
}

Poiché il codice precedente era principalmente correlato allo storage, ho spostato tutto nella mia classe Repository . Ho finito con questo nel mio Controller :

function renumPosition($id)
{
    $this->repository->renumPosition($id);
}

Ho esaminato quanto sopra e ho detto a me stesso - perché ho una funzione nel mio Controller che ha il solo scopo di chiamare un'altra funzione? Perché questa indiretta? Perché il codice ingombra il mio spazio cognitivo e lo schermo quando posso eliminarlo del tutto e completamente. E così ho fatto. Ho chiamato la funzione repository direttamente e ho rimosso completamente la funzione di "reindirizzamento" del controller. Ma poi mi sono chiesto: ho fatto la cosa giusta? Questo è quello che sto cercando di capire con la mia domanda.

    
posta Dennis 24.03.2016 - 19:03
fonte

3 risposte

1

Sì, hai fatto la cosa giusta rimuovendo la funzione renumPosition dal tuo Controller.
Le funzioni devono avere una ragione per esistere e solo il fatto che ci fosse una funzione legittima prima di iniziare a fare il refactoring non è un valido motivo per mantenere la funzione in giro dopo aver refactato le sue ragioni per l'esistenza.

Ci sono due ragioni principali per creare funzioni:

  1. Per ridurre la duplicazione del codice . Se è necessaria una parte di funzionalità in più punti del codice, incapsulare tale funzionalità in una funzione significa che non è necessario duplicare il codice su tutta la posizione (e ritrovarlo se necessita di una modifica o di una correzione di un errore) . Quando crei le funzioni per questo motivo, dovresti tenere a mente anche il prossimo proiettile.
  2. Per creare un'astrazione . Se una parte della funzionalità è costituita da più operazioni, può essere utile per comprendere quel blocco di codice dandogli un nome. Il modo più comodo per dare un nome a un blocco di codice è creare una funzione con quel nome che contiene il codice.

Nel codice originale, la funzione renumPosition nel Controller creava un'astrazione sulle operazioni del database e aveva un motivo per esistere a causa di ciò.
Dopo aver spostato l'interazione del database con il modello, renumPosition in Controller non ha fornito più un'astrazione utile e difficilmente si può sostenere che la duplicazione del codice aumenta se si sostituisce una chiamata di funzione alla funzione A con una chiamata di funzione alla funzione B.

    
risposta data 25.03.2016 - 10:29
fonte
0

Non sono del tutto sicuro di cosa stai cercando di ottenere qui. Se la ragione è la duplicazione del codice in Azioni del controller, è necessario esaminare il livello del servizio che si trova tra il controller e il repository.

Dal tuo controller chiameresti una funzione di servizio _userService.GetUser(5) e quindi puoi usare questa funzione su tutto il controller. La funzione GetUser(int id) gestirà qualsiasi altra cosa che deve fare, incluso effettuare una chiamata al repository, mappare i dati per visualizzare il modello o qualunque altra logica tu voglia.

    
risposta data 24.03.2016 - 19:47
fonte
0

Ci sono due scuole di pensiero quando si tratta della maggior parte della logica dovrebbe essere inserita in un'applicazione MVC: 1) Controller dovrebbe essere stupido e la maggior parte della tua logica dovrebbe essere in Model ; 2) il Model dovrebbe essere stupido e la maggior parte della tua logica dovrebbe essere in Controller .

Entrambi i modi hanno i lati su e giù.

Alla fine, non importa in quale direzione tu scelga finché sei coerente.

Metodo del controller stupido

Questo metodo fa in modo che il controller agisca da agente del traffico per tutti i tuoi modelli.

I metodi del controllore istanziano i modelli e quindi passano il controllo al modello per un'ulteriore elaborazione. Gli stati di errore (inclusi gli errori di convalida) nei Modelli richiederebbero un errore da riportare al Controller (e infine alla Vista). La logica di business della tua applicazione sarà quindi contenuta nei Modelli.

In questo metodo, il modello sarebbe anche responsabile di questo come la registrazione creando un modello di registrazione.

Metodo modello stupido

Questo metodo rende fondamentalmente il tuo modello molto più di un validatore di dati e un meccanismo di archiviazione.

I metodi del controller continueranno a creare un'istanza di Modelli, impostare proprietà e campi, verificare la presenza di errori di convalida o altri stati di errore e comunicare al modello di salvare i dati nella memoria. Gli stati di errore potrebbero essere immediatamente rimandati alla vista. La logica di business della tua applicazione sarà contenuta nel Controller.

In questo metodo, il Controller sarebbe anche responsabile per cose come la registrazione creando un modello di registrazione.

    
risposta data 25.03.2016 - 01:20
fonte

Leggi altre domande sui tag