Originariamente inviato da Santino83_02
ma tu hai un controller legato ad un solo model? oO quindi che controller è? Non è un controller per gestire richieste dell'utente, ma un controller per gestire operazioni sul singolo model?

cioè una cosa del tipo addUtenteToUserGroup te non la puoi fare così, perchè non hai un controller che gestisca un model utente, un model UserGroup, e magari il model usersTogroups in caso di many-many? quindi ci credo che non ci capiamo
Il controller gestisce le logiche del programma. E' quell'oggetto deputato a prendere decisioni ed agire di conseguenza. Questo significa che un controller1 puà fare uso di un model1, un model2 ed un model3.

Io posso stabilire di avere un controller dedicato per ogni view ed il relativo model. Se un domani verrai a metterci le mani trovaerai un controller che decide, un model che agisce sui dati e un viewer che visualizza.

Io posso stabilire di avere più controller, discendenti di un controller genitore, che ridefiniscono i metodi del padre. Ogni controller può interagire con più view, dato che il controller passa se stesso come parametro, e lo stesso controller può interagire con più model che potranno invocare il metodo "notifica" del controller chiamante, qualunque esso sia.

I metodi offerti sono sempre gli stessi, quindi gli oggetti interagiscono comodamente consapevoli di potersi poggiare gli uni agli altri rispetto a tali metodi.

Il nome model della classe è solo per far capire, ma ovviamento si poteva chiamare modelPippo, discendente di modelGenerico che ridefinisce le funzioni del padre, o se preferisci, implementa l'interfaccia (su cui PHP è lacunoso, quindi parliamo di ereditarietà) comune ai model ovvero "aggiorna" e "leggi".
Il view da parte sua può estendersi come il model purchè i suoi eredi implementino o ridefinisceno se necessario il metodo seleziona.

Alla fine di tutto però, entrambi sappiamo che, quando ci toccherà mettere mano al codice, che sia tuo o mio, avremo il model legato ai dati, in controller che decide con le sue routine invocate tramite richiesta dell'utente (ma non spiegiamo come l'utente, non il programmatore, faccia a scegliere la routine da lanciare altrimenti si apre un altro capitolone) e la routine di notifica che incorpora le eccezzioni sollevate dal model. Infine il viewer che, leggendo dal model, ci mostra la pagina.

Il programma si comporta in modo bizzarro... subito apriamo il controllerXXX piuttosto che il controllerZZZ;
il programma salva male i dati? Apriamo il modelYYY o il modelKKK
vogliamo modificare l'aspetto finale? Diamo uno sguardo al viewrFFF