Mvc

[danlupo]

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 ??

[Virus_101]

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

[nickcv]

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.

[danlupo]

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

[nickcv]

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.

[Virus_101]

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.

[Virus_101]

Originariamente inviato da nickcv
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.

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.

[nickcv]

Originariamente inviato da Virus_101
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...

[danlupo]

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.

[nickcv]

Originariamente inviato da danlupo
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