In alcuni progetti le cose potrebbero sembrare simili, ma non le darei alcuna considerazione specifica.
Un controller è fondamentalmente una unità di raccolta di metodi semanticamente correlati (almeno è così che li ho sempre pensati). Probabilmente non è vero tutto il tempo, ma abbastanza per il lavoro di governo, come si suol dire.
Molte volte, questo tende a mappare in qualche modo le tue "principali business logic", in quanto tendi a finire con un controller per Clients
, un altro per Staff
, ecc.
Molto spesso i controllori tendono a seguire un contesto di quali pagine vengono utilizzate. Ad esempio, lavorare con una pagina Client nell'interfaccia utente potrebbe anche avere indirizzi rilevanti da gestire, nel qual caso può avere senso includere un metodo Address
post nel tuo controller Clients
.
D'altro canto, se si utilizza un'API che è destinata a essere condivisa da più sistemi, tali contesti non sono del tutto applicabili. In entrambi i casi però, non penso che troppe persone insisteranno per avere un controller Addresses
per gestire i bisogni di indirizzamento di base di un Client
. Utilizza semantica e gruppi / contesti pragmatici, e i due andranno insieme (in effetti, potrei dire che un indirizzo per un cliente potrebbe essere presentato come parte dell'operazione POST / PUT del client, quindi forse non c'è bisogno di un metodo per gestire gli indirizzi, per non parlare del proprio controller)