I controllori vengono in genere creati per una determinata risorsa (una classe di entità, una tabella nel database), ma possono anche essere creati per raggruppare insieme le azioni responsabili di una determinata parte dell'applicazione. Nei tuoi esempi, sarebbe un controller che gestisce la sicurezza dell'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 email, nome, ecc.
Con i controller creati per le risorse (diciamo Task ), avresti il solito CRUD azioni:
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()
}
Ovviamente, hai la possibilità di aggiungere risorse correlate allo stesso controller. Supponiamo ad esempio che tu abbia l'entità Business , e ognuna ha diverse% di% di esclusioni.
Un controller per questo potrebbe apparire come questo:
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à figli correlate non possono esistere senza l'entità genitore.
Questi sono i miei consigli:
- crea i controller in base a un gruppo di operazioni correlate (gestendo determinate responsabilità come sicurezza o operazioni CRUD sulle risorse ecc.);
- per i controller basati su risorse, non aggiungere azioni non necessarie (se non si desidera aggiornare la risorsa, non aggiungere l'azione di aggiornamento);
- puoi aggiungere azioni "personalizzate" per semplificare le cose (es. hai un'entità
BusinessService che ha una disponibilità basata su un numero limitato di voci, puoi aggiungere una nuova azione al controller chiamato Subscription che ha il scopo singolo di sottrarre una voce da use() )
- mantieni le cose semplici - non ingombrare il controller con un numero enorme di azioni e una logica complessa, prova a semplificare le cose riducendo il numero di azioni o creando due controller;
- se utilizzi un framework focalizzato su MVC, segui le linee guida sulle best practice (se ce l'hanno).
Alcune risorse per ulteriori letture qui .