I controller vengono in genere creati per una determinata risorsa (una classe di entità, una tabella nel database), ma possono anche essere creati per raggruppare azioni responsabili di una determinata parte dell'applicazione. Nei tuoi esempi, sarebbe un controller che gestisce la sicurezza per l'applicazione:
class SecurityController
{
// can handle both the login page display and
// the login page submission
login();
logout();
register();
// optional: confirm account after registration
confirm();
// displays the forgot password page
forgotPassword();
// displays the reset password page
// and handle the form submission
resetPassword();
}
Nota : non inserire le azioni relative alla sicurezza e le azioni del profilo utente nello stesso controller; potrebbe avere senso perché sono correlati all'utente, ma uno dovrebbe gestire l'autenticazione e l'altro dovrebbe gestire gli aggiornamenti di e-mail, nome ecc.
Con i controller creati per le risorse (diciamo Task), avresti le solite azioni CRUD :
class TasksController
{
// usually displays a paginated list of tasks
index();
// displays a certain task, based on an identifier
show(id);
// displays page with form and
// handles form submission for creating
// new tasks
create();
// same as create(), but for changing records
update(id);
// displays confirmation message
// and handles submissions in case of confirmation
delete()
}
Naturalmente, hai la possibilità di aggiungere risorse correlate allo stesso controller. Supponiamo ad esempio di avere l'entità Businesse ognuna ha diverse BusinessServiceentità. Un controller potrebbe essere simile al seguente:
class BusinessController
{
index();
show(id);
create();
update(id);
delete();
// display the business services for a certain business
listBusinessServices(businessId);
// displays a certain business service
showBusinessService(id);
// create a new business service for a certain business
createBusinessService(businessId);
// updates a certain business service
updateBusinessService(id);
// deletes a certain business service
deleteBusinessService(id);
}
Questo approccio ha senso quando le entità figlio correlate non possono esistere senza l'entità genitore.
Questi sono i miei consigli:
- creare controller basati su un gruppo di operazioni correlate (gestire determinate responsabilità come la sicurezza o operazioni CRUD su risorse ecc.);
- per i controller basati su risorse, non aggiungere azioni non necessarie (se non si prevede di aggiornare la risorsa, non aggiungere l'azione di aggiornamento);
- puoi aggiungere azioni "personalizzate" per semplificare le cose (ad esempio hai
Subscriptionun'entità che ha una disponibilità basata su un numero limitato di voci, puoi aggiungere una nuova azione al controller chiamato use()che ha il solo scopo di sottrarre una voce dalla Subscription)
- mantieni le cose semplici: non ingombrare il tuo controller con un numero enorme di azioni e logiche complesse, cerca di semplificare le cose diminuendo il numero di azioni o realizzando due controller;
- se stai usando un framework focalizzato su MVC, segui le loro linee guida sulle migliori pratiche (se ce l'hanno).
Alcune risorse per ulteriori letture qui .