Originariamente inviato da Grino
Ok tutto giusto, magnifico ma non mi spieghi perchè c'è una freccetta tratteggiata che va dal model fino al controller nello schema di Zend.

Mi vorrai mica dire che hanno inserito un fronzolo?

Io la mia piccola soluzione per rispondere a chi ha fatto una domanda l'ho data. E' nel terzo post. Non è certo una soluzione da produzione ma è qui. La vostra dov'è? La critica l'accetto se porta soluzioni. Qual'è la vostra soluzione?

Postate del codice... ci arricchiremo tutti!
come ho detto, la riga tratteggiata indica l'interazione tra due elementi, nel caso specifico ritengo chiamate a metodi e loro ritorni, ma non è spiegato. E seppur fosse l'observer, ovvero far scaturire eventi che poi altri usano per modificare il proprio stato, ripeto l'idea che in app stateless come generalmente è una webapp, è una cosa inutile e irrealizzabile, e nello specifico veniva considerato come (ottimo) metodo per dire alla view che si doveva aggiornare.


Vuoi un esempio? ma come, mi citi la bibbia delle bibbie con Zend, e poi chiedi a me un esempio?

http://www.framework.zend.com/manual...ate-model.html

solo in questa pagina c'è l'esempio di un model e di un controller e non mi pare che ci siano eventi che si scatenano

notare che l'oro incapsulano l'entity del database nel model, con solo getter e setter praticamente. Poi usano quelli che chiamano Mapper (che mi ricorda tanto il caro vecchio pattern DAO) per operazioni del tipo "save","find","findAll", o se preferisci, "salva","trova","trovatutti", e il controller non fa altro che dire:

caro guestbookMapper, mi ridai tutti i messaggi lasciati dall'utente? grazie, ora che li ho tutti li do alla mia view così li renderizza come meglio crede...e lì che la view può essere una pagina html, una pagina xml, una json, etc etc etc senza che il controller sappia nulla, senza che il model sappia nulla, senza che il controller debba sapere come comportarsi col model, senza che il model sia costretto ad invocare eventi per altri oggetti etc etc...

il model è una merdina che conosce solo di se stesso
il mapper è una merdina che sa solo compiere operazioni CRUD sul suo model di riferimento
il controller è un ebete alfabetizzato che compie meccanicamente le operazioni che rappresenta
la view è un semplice "render"

direi lineare. e semplice. questo vuol dire che se cambia il model internamente al controller non gliene frega nulla, basta che il contratto non cambi. questo vuol dire che al model non interessa chi lo sta usando, lui fa il suo lavoro e basta. questo vuol dire prendere un model da un progetto e buttarlo in un altro progetto senza star troppo a guardare chi e come lo usa, senza modificare classi esistenti per accettare contratti diversi. Questo è, in definitiva, lo standard attuale che si applica nella stragrande maggioranza dei casi e che prende spunto da principi di programmazione ben precisi il cui rispetto rigoroso giova, anzi è indispensabile, alla riusabilità e manutenzione del codice proposto.

soluzioni fighissime possono naufragare miseramente quando si deve mantenerle e modificarle o aggiornarle.

questo non vuol dire che tu abbia scritto una schifezza, intendiamoci. E' che a vedere un manuale di oop, a vedere che sai in una web app, a vedere che "dici" di usare un determinato pattern, a vedere il risultato finale, secondo me stai sbagliando concettualmente determinate scelte, complicandoti la vita e ingarbugliando il codice. Detto questo, tu sei liberissimo di fare come ti pare per carità. Solo che se mi dici "mvc", l'mvc è una cosa ben precisa, strausato/abusato, quello che dici te, no.

Tanto poi per tornare a teorizzare, in applicazioni dove il programma non "muore" dopo la prima richiesta, ma vive per tutto il tempo di utilizzo (leggasi programmi desktop o simili), pattern come l'mvc non vengono adottati (o meglio, io non ho mai visto un mvc in un programma desktop), o meglio ancora, sono sviluppati differentemente (vedi gli handler di eventi di un file cs in .net che rispondono molte delle volte a interazioni dell'utente col programma).


edit: poi vabbeh, ormai penso che si stia andando in OT o cmq in una discussione che non arricchisce il 3D