Cosa definisce il tradizionale concetto di "pagina" in MVC?

Question

Attualmente utilizzo CodeIgniter come framework per l'utilizzo di PHP. Una delle cose con cui sto combattendo è l'idea di una "pagina", e come rappresentarla correttamente all'interno di MVC. A mia conoscenza, CodeIgniter ha un front controller che delega ai controller di pagina. Nel mio processo di pensiero, ogni pagina avrebbe il proprio controller. Troppo spesso però vedo qualcuno che usa un controller di pagina pieno di molti metodi. Quindi in questo senso, ogni azione diventa la sua pagina.

Non mi è mai piaciuta l'idea di inserire molti metodi in un controller, perché sembra che ci sarà troppo sovraccarico se è necessario un solo metodo o due nel controller alla volta. Sembra più ragionevole per ogni pagina avere il proprio controller e le azioni corrisponderanno solo a qualcosa che puoi fare su quella particolare pagina. Sto pensando a questo nel modo sbagliato?

Ciò che rende più confuso è che noterò in alcune applicazioni Web in cui avranno un controller che avrà più metodi (ad es. Login, registrazione, visualizzazione, modifica, ecc.), Ma poi su altri hanno effettivamente un controller di login e un controller di registro. Qual è l'uso corretto di un "controller di pagina"?

Answer 1

Da un punto di vista del dominio, dico decisamente che ha più senso disporre di 1 controller per contesto di dominio. Non necessariamente uno per pagina, anche se a seconda del contesto questo potrebbe essere il caso. Ciò che intendo per contesto è "le azioni strettamente correlate".

Ad esempio un controller di account deve gestire l'accesso, registrare, disconnettersi, cambiare password, azioni. Vivono tutti nel contesto di un "Account"

Prendere StackOverflow ad esempio. Avrei un controller "Domande" che avrebbe azioni come DisplayQuestion, AskQuestion, Delete Question, MostRecent Questions, ecc. Sono tutte "Views/pages" diverse gestite da un controller.

Answer 2

Hai ragione nel fatto che ogni metodo pubblico in un controller diventa una "pagina". Detto questo, non è necessariamente una pagina web, un'azione potrebbe essere un post di dati e quindi reindirizzare a un'altra azione/pagina quindi la pagina non significa necessariamente "pagina web".

MVC utilizza molte convenzioni per far funzionare le cose. Ad esempio, ogni controller deve terminare con "Controller". Quindi una serie di pagine utente (creare, modificare, eliminare, ecc.) Si troverà in un UserController. Nella cartella Viste, ogni metodo o azione pubblico all'interno della classe controller diventa una pagina Web all'interno di una cartella che corrisponde al prefisso del controller (in questo caso, una cartella Utente). Quindi un'azione denominata "Elimina" all'interno della classe controller punta alla pagina Delete.aspx all'interno della cartella Utente.

Sembra un po 'imbarazzante mettere tutti questi metodi in una classe, ma fa un buon lavoro nell'organizzare funzionalità simili basate sul tuo oggetto.

Answer 3

In MVC, una "pagina" è ciò che ottieni quando metti i tre insieme. Il modello gestisce il livello dati, la vista gestisce l'HTML effettivo che l'utente vede e il controllore decide in che modo interagiscono per mostrare i dati desiderati. La mia scelta di utilizzare un controller separato o un altro metodo su un controller esistente dipende dalla vicinanza dell'operazione agli altri controller che ho. Supponiamo che volessi un controller UserAdmin, che ora probabilmente gestirà l'aggiunta di un utente, l'eliminazione di un utente, la modifica delle password, ecc. Se aggiungessi funzionalità che si occupavano di modificare l'account di un utente in qualche modo, molto probabilmente lo inserisco lì dentro. Se li avessi separati nel loro controller, ne aggiungerei naturalmente un altro. I controller ti consentono di organizzare insieme attività simili in modo che possano sfruttare ciò che è già nella classe, piuttosto che dover ricreare ciò che è già stato fatto. Molto è come il programmatore pensa che dovrebbe essere fatto.Ciò che ha senso per te potrebbe non avere senso per me, è la scelta dello sviluppatore (o del progettista).