Newsgroup: it.comp.lang.delphi
Titolo: Delphi, MVC e Observer pattern

Ciao a tutti,
Nel thread sulla finestra che deve sapere se mostrarsi ad un utente
(
http://groups.google.com/group/it.comp.lang.delphi/browse_thread/
thread/c416f40d4da1c597) si è aperta una discussione sul paradigma
MVC.
Apro allora questo thread perché mi piacerebbe parlarne e lo faccio
riprendendo quanto si scriveva nel thread precedente:
[Matteo]
Delego tutto ad un controllore (C?) dal quale passare per vedere se è
possibile aprire o no la form
[Morde]
Conosci il pattern MVC, il model view controller? Non dico che devi
implementarlo, ma il concetto di avere a disposizione un controller al
quale delegare queste responsabilità è sempre comodo.
Tu vuoi aggiungere logica ai form, io invece credo che lo scopo del
form essenzialmente sia di gestire le informazioni da visualizzare
(presentation layer). Io lascio decidere ad un controller se
quell'utente ha le credenziali o meno per aprire una finestra.
Quanto dice Morde è giustissimo ma non mi pare che il modello di
programmazione di Delphi, e in generale quello visuale, vada in questa
direzione. Mi spiego meglio:
In estrema sintesi MVC prevede (perdonate la semplicità):
1. Classi di modello dove si mette la logica di business (il lavoro
vero dell'app.).
2. Classi di controllo: delle piccole procedure (un telecomando) che
chiama i metodi di business nella giusta sequenza. e istruiscono la
GUI ad alcune cose.
3. classi di visualizzazione: responsabili della creazione e
visualizzazionde dei dati, dell'aspetto della finestram, etc.
La programmazione visuale di Delphi, come quella di VB, in generale ha
le classi di tipo 2 e 3 fuse insieme. L'evento OnClick di un bottone è
l'esempio più eclatante:  esso è di fatto il controller che viene
invocato dall'esterno ed esegue i comandi necessari. Sta poi al
programmatore cercare di tenere questi controller semplici e lineari
delegando il lavoro di business ad ulteriori classi.
Ovviamente il linguaggio Delphi, essendo un buon linguaggio OO, ti
permette di implementare il paradigma MVC, ma sicuramente gli IDE per
Delphi, con il loro "core" basato sul click del mouse sui pulsanti per
aprire un piccolo editor dove scrivere il comando da eseguire, non ti
porta naturalmente a scrivere un'applicazione MVC. Ti porta di più a
scrivere un'applicazione GUI-driven.
Ora tutti sappiamo che se l'applicazione ha un grado di complessità
anche solo medio, il modello GUI-driven di ti porta facilmente, ma non
necessariamente, al caos e quindi cerchiamo di attenuarlo forzandoci
comportamente più rigorosi come quello proposto nel thread di cui
sopra.
Ma se ci pensate neanche quello è un vero MVC. Io lo vedo più come un
Observer: la finestra, prima di fare qualcosa, chiedo all'Observer se
la posso fare. L'Observer, che conosce lo stato dell'applicazione, gli
da l'autorizzazione o meno.
La questione che apro qui, quindi è la seguente:
Conviene "combattere" il modello naturale della programmazione visuale
cercando di implementare un MVC? O è meglio tenerlo a bada usando
pattern tipo Observer? O è ancora meglio assecondarla  e scrivere
tutto nei metodi OnXYZ?
Ciao,
Gianpiero
--
Nintendo Wii-like front-end
http://sourceforge.net/projects/wiilauncher/

 tutto nei metodi OnXYZ?
Io opto in genere per observer, ma se serve uso mvc.
il cosidetto "modello naturale" non è un modello...La possibilita di
usarlo sfocia in 2 risultati diversi
Se lo usa uno che sa stare al mondo, verrà usato per cose vermanete
spot, semplici, di supporto/test etc etc etc
Se lo usa uno che non trova il suo culo manco con un navigatore il
risultato sara una app di livello interprise...
E clienti, customer service e sviluppatori addetti a debug e
refactoring saranno immensamente felici... :-((
A.

 tutto nei metodi OnXYZ?
Non esiste soltanto il pattern MVC che diventa pesante quando devi 
reimplementare praticamente tutti i controlli visuali. A me piace molto 
anche MGM, ad esempio, perch� comunque consente di usare i controlli 
visuali rendendoli objectaware: 
http://www.andypatterns.com/index.php/design_patterns/model_gui_mediator_pattern
Implementazioni di questo pattern sono in tiOPF, per cui � agevole 
cercare di capire il loro funzionamento eventualmente ricorrendo ai loro 
newsgroup.
Per quanto riguarda la convenienza questa � una valutazione che ognuno 
deve fare in base alle proprie conoscenze, alla velocit� di scrittura 
del progetto, alla dimensione che questo raggiunger�, alle possibili 
estensioni che dovr� avere, ecc.. Le variabili sono molto, io propendo 
sempre per il s�, ovvero scrivere un applicazione completamente OO con 
classi di business completamente slegate sia dal db che dall'interfaccia 
visuale.
Antonio

 tutto nei metodi OnXYZ?
Hai posto un'interessante domanda, e la risposta non puï¿œ essere che una 
sola: dipende. :)
Dipende dal programmatore, dal suo skill, dalla sua esperienza, dal 
tempo che hai a disposizione, dal budget, ecc...
Non voglio buttare fumo sugli occhi e rendere prolisso il mio discorso, 
ma la veritï¿œ ï¿œ che in "real life" la realizzazione dei progetti e' 
fortemente condizionata da questi fattori.
To parli di delphi che e' gui-driven. In realtï¿œ sarebbe event driven, 
ma al di lï¿œ dei distingui e pignolerie varie, dobbiamo sempre tener 
conto che dietro a delphi c'ï¿œ proprio una pensata di questo tipo, un 
RAD.
E' il RAD che e' stato pensato per lasciarti gestire solo gli eventi, 
pensando lui al resto (instradamento messaggi,observing, ecc..)
Non conosco il codice della VCL, ma so che e' orientato a questo 
approccio: event driven.
Se io potessi, per ogni progetto sceglierei un approccio fondato sui 
pattern, di conseguenza userei i pattern per il disegno, i pattern per 
l'implementazione e i pattern per il comportamento. Purtroppo qui siamo 
nel matrix (io scelsi la pillola blu a suo tempo..) pertanto capita al 
99% delle volte che per un'implementazione devo realizzare una funzione 
in poco tempo, pertanto mi affido al trascinamento dei controlli VCL 
sul form, e alla scrittura di codice nell'event handler che mi 
interessa.
Se dovessi rinascere, la prossima volta sceglerei la pillola rossa, in 
modo che alla domanda <<morde, lo conosci il pattern XYZ?>> potrei 
rispondere come fece trinity per guidare l'elicottero: "NOT YET" e un 
secondo dopo farmi fare l'upload di tutto il POSA4 (che sto studiando 
da due anni..) e impararlo istantaneamente!!
Scherzi a parte, GianPaolo, credo che la risposta giusta sia che tutte 
le soluzioni sono valide, poi c'ï¿œ quella piu' buona e quella meno 
buona, ma sono discorsi che senza un riferimento preciso non possono 
che restare generici..
Un saluto!
-- 
Morde

 creando quindi dei form pesanti, inutilizzabili, ingestibili
qualsiasi linguaggio usino, questi faranno sempre delle schifezze.
Concludo riaffermando quanto penso: se proprio il modello di
programmazione che mi offre una certa tecnologia non mi aiuta in
quello che devo fare, io cambio tecnologia. In termini pratici,
pensando a Delphi, un ottimo RAD event-driven (scusate per il "GUI
driven") ragiono perl'appunto ad eventi.
Il MVC faccio fatica ad usarlo con Delphi e bisognerebbe mitigaare le
possibili skifezze fatte dagli "imbecilli" usando, all'occorrenza,
pattern tipo Observer.
Ciao,
Gp