Controller in MVC

@ DavinTyon ha risposto molto bene, ma penso che ci siano altre due cose da menzionare. Nel bene o nel male, la parte router / controller di MVC è funzionale . La gerarchia funziona così:

• Il router prende l'URL e scopre quale funzione dovrebbe chiamare
• Il controller funge da modulo per incapsulare le funzioni correlate
• L'azione è la funzione specifica che viene chiamata

Ciò si adatta bene con la funzionalità di mappatura allo spazio URI. Una cosa che i motori di ricerca ci hanno insegnato è che gli URI sono importanti. Influenzano il nostro ranking delle pagine e sono contratti per i consumatori (utenti o macchine) che puoi ottenere una risorsa in questa posizione.

L'azione specifica è un insieme di istruzioni su come preparare la risorsa per la richiesta. Mescolare approcci funzionali e orientati all'oggetto si sente sconnesso e difficile da avvolgere in molti casi. Sfortunatamente, quando costruiamo sistemi sempre più distribuiti, l'influenza della programmazione funzionale aumenterà solo.

MVC tenta di aiutare a superare questa separazione:

• I controllori sono moduli di azioni correlate (funzioni)
• Le azioni preparano le risorse per i modelli di visualizzazione
• I modelli sono orientati agli oggetti e sono dove si applicano tutti i principi orientati agli oggetti.

Penso che questo sia un modo migliore per avvolgere la nostra mente su un'applicazione MVC e ci aiuta anche a trovare i giusti schemi e principi di progettazione per i vari pezzi.

Anche uno dei principali driver di MVC stava migliorando la capacità di test. È possibile eseguire le azioni su un controller senza un server Web o un'infrastruttura completa disponibile. È anche possibile testare il contenuto del modello e del ViewBag passati nell'oggetto View restituito da un'azione. Il modello rimane testabile come lo hai progettato. L'ultimo elemento per assicurarsi che la vista sia corretta rimane un processo manuale, ma le parti più rischiose dell'app possono essere completamente testate.

Penso che tu ti stia riferendo al Principio di Responsabilità Unica (SRP) . Che, in sintesi dichiara:

that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class

Tuttavia, questo non significa che one class should only do a single thing . In significa che una classe o un modulo dovrebbero avere solo una ragione per cambiare :

Robert C. Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change.

Quindi, nel tuo esempio di /user/edit e /user/view , il controller è responsabile dell'esposizione di user a qualcosa oltre il limite dell'applicazione, come una vista.

Più in alto nella pila ottieni (o più aggregati per la visualizzazione), più dipendi implicitamente. Il pattern MVC è un modo per minimizzare questo. Separando le responsabilità nella preparazione dei dati per la visualizzazione. MVC può inoltre essere suddiviso in sezioni verticali nell'applicazione (ad esempio user ). Questo sposta il design dell'applicazione sempre più verso SRP. Questo è il migliore che abbiamo al momento. Esistono altri modelli (come MVP e MVVM ) e forse un giorno ne emergerà uno migliore e sarà adottato.

SRP è un principio, il che significa che dovremmo prendere in considerazione e adoperarci per la progettazione delle applicazioni. Ma dobbiamo anche essere pragmatici e fare le cose. Quindi, c'è un compromesso.

Lo scopo del modello di progettazione IMHO, Model-View-Controller (MVC) è quello di separare il problema applicativo in Dati (modello), Presentazione (vista) e Business logic (controller) per aumentare la riusabilità e la manutenibilità del codice [1] [2] . Nel modello di progettazione MVC, il componente controller contiene tutti i metodi dell'applicazione che hanno lo stesso dominio. Diciamo che metterà in UserController tutti i metodi che riguardano l'utente (login, registrazione, aggiunta, eliminazione, ecc.) Con SalesController che conterrà tutti i metodi relativi alle vendite.

Quindi, penso che sia più chiaro e più pulito raggruppare il tuo metodo che ha lo stesso dominio nell'unico controller invece di creare controller per ogni metodo :). Anche se non ho mai testato le prestazioni (es: caricamento della classe nel tuo caso), ma credo che php e web server lo gestiranno per te in background.