Un controller per pagina o più pagine in un controller?

È meglio avere un controller per unità logica, ad esempio AccountController (login, registrazione), PagesController (home, contact), Backend - > PagesController (crea, modifica, elimina), UsersController (crea, modifica, elimina) e così.

@Rushino Qui ci sono due "app": il front-end (per i lettori) e il back-end (per gli amministratori). Per ogni gruppo di funzionalità, hai un controller.

L'accesso è un tale gruppo, che include la generazione del modulo HTML (i campi, chiamando la vista) e la gestione del modulo (la convalida, la connessione con il modello). Quindi 'login' è un controller con due azioni - generateForm e handleForm.

Le pagine sono divise tra l'app di front-end - che mostra solo le pagine - e l'app di back-end che consente di modificare, eliminare, creare e possibilmente visualizzarle in un modo diverso. La homepage è "solo un'altra pagina" sul front-end almeno, quindi si adatta al controller delle pagine. Sul backend, la sua logica potrebbe essere abbastanza diversa da giustificare completamente un controller diverso.

Per gli utenti - se gli utenti possono registrarsi, hanno bisogno di un controller di frontend, ma in caso contrario, tutto ciò che riguarda gli utenti va nel back-end.

Si noti che ciascuna delle funzioni di back-end può richiedere sia un generatore che un gestore. Queste cose possono essere suddivise in file di configurazione, però, con un plugin che è un generatore di moduli generici.

In breve, assomiglia a questo:

Frontend
  Pages
    View, Handle
  Login
    View, Handle
  Users
    Register (note that the handler can be the same as 'create' on the backend)
  Contact
    View
    Handle

Backend
  Users
    Create, Delete, Edit, Update, View
  Pages
    Create, Delete, Edit, Update, View

Penso che dovresti usare un Controller per unità di business, come OrdersController per tutte le operazioni relative agli ordini e simili. Sono consapevole del fatto che in questo caso, i controllori ottengono ENORME, ma possiamo ancora utilizzare le classi helper per delegare elementi come l'inizializzazione del modello e le classi parziali per distribuire le azioni in file separati.

Ad esempio, posso avere OrdersController Create.cs and OrdersController file List.cs per la classe OrdersController ognuno con il set corrispondente di Azioni. Rende le cose molto più pulite e mantiene le operazioni degli ordini centralizzate in una singola classe di controller.

Solo i miei 2 centesimi.

Penso che potresti adottare un approccio diverso:

Un controller principale come porta frontale che fornisce la richiesta a specifici controller. In questo modo puoi utilizzare questo front controller per controllare elementi comuni come l'autenticazione dell'utente, google analyics e qualsiasi altra cosa generale che vorresti fare e mantenere pura la struttura MVC.

Questa non è la mia idea, ma Symfony Framework funziona in questo modo, quindi posso dirti che per mia esperienza questo è un

è un modo davvero carino ed elegante per implementare un frontend.