Salve, chiedo scusa subito ai guru del forum.
Oggi ho sentito parlare di MVC ed ho deciso di approfondire questo campo che per me era oscuro venendo da programmazione totalmente procedurale.
Vorrei chiede alcuni chiarimenti su quello che ho letto e capito da documentazioni e tutorial vari.

Allora l'MVC è diviso in tre macro aree il view che rappresenta la parte visuale (quindi penso sostanzialmente codice HTML) il Controller che si occupa di far interagire il server con gli utenti (tramite la sezione view) ed il Model dove sono racchiusi i vari metodi e le funzioni.

Quindi se ho capito: Inizializzo Il controller con il metodo constructor, richiamo i metodi della sezione model che poi vengono portati a video tramite il codice preparato nel view.

Mi sbaglio ??

Si .

MVC applicato al web va trattato con i guanti.
MVC nasce cmq per la parte programmi stand alone e poi e' stato applicato al web, e per fare questa etrapolazioni devi fare a volte uno sforzo soprattuto se hai parti in ajax etc...


Ultimamente (purtroppo) sta diventando uno std per lo sviluppo delle app su internet ... e dico purtroppo poiche ci sono pattern decisamente migliori.
Se php supportasse la peristenza mvc morirebbe a favore del factory pattern

cmq inizia a guarda da qui : http://it.wikipedia.org/wiki/Model-View-Controller

ogni entità ha le sue classi, ogni entità interagisce con le altre con determinati scopi.

ad esempio :

- (view) html + form
~ utente esegui submit
- (controller) gestisce input utente
- (controller) utilizza model per accessi e gestione dei dati
- (model) carica/aggionra/elimina dati
- (controller) prepara i nuovi dati per la response
- (controller) gestisce la response
- (view) si aggiorna in base alla response e ai dati del model


sinceramente mcv su web lo trovo abb ostico e non capisco perche' sia cosi' famoso.
Factory e' decisamente meglio :

- avvia facotry di creazione pagina
- crea pagina
- visualizza form
~ submit
- raggiungi il gestore delle interazioni(una sorta di controller)
- avvia factory_interactionHandler::getInstance()
- gestisci request
- avvia factory relativa al modulo richiesto
- esegui response.
- ri-rendereizza pagina

QUesto pattern e' molto comodo se puoi usare la persistenza, rende le web apps iper performanti purtroppo ... non e' tua necessità ne php supporta persistenza ... per cui MVC ....
beh funziona cosi'.

Oggi come oggi io sto ponderando di scindere le mie web apps in 2 applicazioni distinte.

1- app server solo PHP
2- app client solo js

cosi' posso tranquillamente applicare i pattern che preferisco.
Lato client mvc va bene ma server posso usare factory o altro

mvc permette di dividere i vari layer di un applicazione, cosa che il "factory" non ti permette di fare...

comunque factory è un design pattern per la creazione di oggetti, lo stesso MVC usa un factory nell'ORM quando viene fatto il retrieve di dati.

ad ogni modo dividere i layer è la cosa migliore, inoltre se si evita troppo coupling è possibile riutilizzare moltissimo codice cambiando progetto.

Io pensavo, forse erroneamente, che non esistesse OOP senza MVC.

Io posso sviluppare PHP con l'utilizzo di classi ed istanze senza per questo dover utilizzare un MVC.

Perchè io sto sviluppando il mio primo progetto di una certa grandezza (per i miei standard) con area utenti, messaggistica interna, gestione eventi e volevo fare qualcosa di più performante di una serie di file. Quindi sto vagliando ogni possibilità per far rendere al meglio il progetto.

Daniele

sì puoi sviluppatore ad oggetti senza usare alcun design pattern...

MVC è solo una delle soluzioni più efficaci in quanto ti permette di avere codice più facilmente mantenibile e più facilmente riutilizzabile.

Allora OOP e' un paradigma , ossia una serie di specifiche che definiscono un qualcosa.In questo caso il paradigma OO (Object Oriented) specifica il comportamento di un linguaggio ad oggetti.
Ma lo specigfica a livello di linguaggio non del suo utilizzo.

E' come dire questo strumento e' una pala.

Poi dipende da te che tecnica usi con la pala

E qui entrano in campo i "design patterns" (tra i quali mvc) , questi cosi dal nome altisonante, altro non sono schemi architetturali prefatti per creare un software.
Su software di media/grandi dimensioni si rendono necessari proprio perche' qualsiasi programmatore possa capire al volo la struttura dell'applicazione indipendentemente dalle entita dell'applicazione stessa.

Tornano a noi, MCV o MVC che dir si voglia e' appunto uno dei design patterns standanrd che che ti dice come usare la pala.

quindi OOP e' quello che usi come strumento,
i design patterns sono gli schemi di produzioni
dopo resta a te progettare correttamente le classi e le entità del sistema in accordo con il pattern prescelto.

Beh non e' proprio vero.... la cosesione di mvc e' pazzesca... ci sono apttern decisamente migliori.
MVC e' uno dei primi pattern che si imparano ad usare per la sua semplicità di base ... ma piu' ci lavori sul web ... piu' capisci che factory o PAC sono migliori.

questione di gusti, virus, e lo sai :P
nessun design pattern è la panacea di tutti i mali, e questa è la prima cosa che ti viene insegnata.

comunque il coupling in mvc non è così tragico, per quanto sicuramente un factory per definizione stessa non ha alcuna forma di coupling.

ad ogni modo bisogna distinguere dal fatto che indipendentemente dal design pattern che viene utilizzato a livello globale di applicazione al suo interno vengono sempre utilizzati più design pattern:
Factory per l'ORM
Singleton per la gestione di alcuni component
Registry per la gestione delle configurazioni globali di un'applicazione,
Observer per la gestione di eventi

ecc ecc...

Io vi espongo la mia situazione che è piuttosto semplice e potrebbe essere suddivisa in tre macro aree:

La prima pubblica composta più che altro da pagine descrittive, una pagina di esposizione di eventi mediante calendario e popup (gestito tramite libreria jquery, ui e Fullcalendar) e due pagine semplici di modulo informazioni ed un unisciti a noi (molto simili tra loro cambia solo la sezione messaggio);

La seconda area è quella privata, accesso tramite login, sezioni modifica profilo e password(gestito come tabella e query SQL), sistema di messaggistica interna (sempre tramite sql) possibilità di download file e comunicati (qui uso un semplice script basato sulla funzione glob ed il cambio di estensione ed una sorta di agenda eventi (simile a quella pubblica).

L'ultima macro area è quella di amministrazione con la gestione degli utenti, la gestione degli eventi (che si traducono sostanzialmente in un insieme di query con gestione tabelle e record).

Sostanzialmente l'utilizzo di un design pattern e della 'pala' OOP mi potrebbero essere molto d'aiuto nella gestione degli utenti, della messaggistica e degli eventi; solo che, essendo un progetto fatto nel tempo libero a livello volontario, volevo fare un buon lavoro senza però doverci perdere la testa, per questo sto vagliando quale architettura usare basandomi principalmente sulle mie conoscenze.

io personalmente farei il tutto con Yii e la chiuderei lì.
ma da capo ad ognuno il suo

@nickcv certamente sno daccordo con te. Nulla da dire . IL fatto e' (ovviamente e' un parere personale) non sono un gran fan di MVC per applicazioni web. Porprio vista la continua necessità di modifiche ed evoluzioni di queste tipologie di software. E appunto l'alta coesione che hanno i componenti unitamente al fatto che di fatto gesdtisci 2 software diversi(1-clint pagina web e 1 app server side) rendono MVC abb ostico su web.

Per questo preferisco factory. SOlitamente definisco le mie fabbriche con i relativi "operai" a cui do in pasto i dati e i quali con i relativi strumenti a loro disposizione gestiscono il tutto.

Ho guardato Yii ma non mi convice molto forse e' meglio kohana (design PAC) che e' davvero 1 bombardata

Si un Framework puo' essere comodo ma dipende da danlupo come vuole procedere.
Se vuole imparare un fw e usare quello o preferisce avere il controllo completo di tutti i componenti dell'app. Anche re-inventando la ruota.

eheheh sapevo avresti suggerito un fw PAC XD

comunque vedi tu danlupo, e non farti problemi perchè tieni a mente che non esiste una risposta giusta od una sbagliata su quale design pattern voler utilizzare, entrambe le soluzioni hanno i loro pro e contro.

assolutamente daccordo.

Nel tuo caso ... se proprio vuoi usare MVC costruisci delle buone piramidi
(in lingua jedi devi strutturare bene gli alberi di classi che comporranno il tuo software)

Facendo un AUTOQUOTE da un'altra discussione

Preferisco non reinventare la ruota vistoche rischierei di farla quadrata quando in realtà ci sono persone miliardi di volte più in gamba di me che hanno creato codici già pronti e riutilizzabili.

Io nasco informatico ma sono diventato cuoco ed ora faccio siti solo per 'divertimento' o per favori ad amici. Il mio unico approccio prima di oggi con i Framework è stato quello disastroso con lo Zend.

Mi ha 'incuriosito' questa definizione di Virus

.

Purtroppo on web ho trovato poco a livello di tutorial (a parte alcune diapositive ed una pagina di una dispensa universitario, ho trovato solo un esempio su MVC) e mi piacerebbe poter approfondire l'utilizzo di un framework in modo da potermi fare una base anche per eventuali progetti futuri..

Capisco per questo ti consigliamo l'uso di framework perche' appunto ti fornisce tutto un amibente prefatto per poter manipolare le entitca che devi gestire.

Il discorso factory da me accennato sopra riguarda prettamente tale design pattern.
Quel pattern e' molto comodo su sistemi tipo tomcat/glassfish e java servlet, in quanto puoi sfruttare la persistenza.
QUindi le factory non sono altro che classi statiche(in java veramente statiche) che istanzi 1 volta all'avvio dell'applicazione e poi restano disponibili fino al successivo riavvio dell'applicazione stessa.

Non vengono quindi ri-allocate ogni volta ma semplicemente ri-utilizzate quando invocate
ad es :
userManager um = factory_userManager::getInstance();
user u = um.getCurrentUser();

la classe userManager verrà allocata ed instaziata al primo avvio e quindi ri-utilizzata dai moduli dell'applicazione. Ma questo in php non lo puoi fare poiche non hai la gestione della persistenza.

Puoi usare qualcosa che ci si avvicina con i singleton (o classi pseudostatiche come le definisco io :P ) quindi puoi creare una factory che produce operai.
E le altre factory che usano tali operai per compiti x.

ad esempio

$worker = f_getWorker( "userManager" ) ;

f_actionManager::giveJobToWorker( $worker , $job ) ;
// OPPURE
$jm = f_jobManager::getInstance();

try{

$jm->giveJobToWorker($worker,$job)

}catch(Exception $w){var_dump($e);die();}


Puoi gestire quindi l'applicazione come una serie di workers che eseguono determinati jobs

ALla fine con il apttern factory puoi divertirti come ti pare