[Generale]UI: messaggi tra forms

[RaouL_BennetH]

Ciao a tutti :)

Classica applicazione MDI, un form 'Main' e tanti child.

Inizialmente, per testare alcune cose, mi sono limitato a settare come public alcuni controlli sul Main, tipo delle label. All'apertura dei vari child, a queste label viene assegnato quindi, un semplice valore proveniente dal child del caso.

Riesco ad ottenere la stessa cosa utilizzando dei delegate(perchè utilizzo C#, ma immagino che con qualsiasi altro linguaggio si possa fare la stessa cosa) che si occupano dello scambio dei messaggi tra i forms lasciando "in privato" i controlli sul Main.

In termini di "prestazioni", non sono capace di valutare cosa funzioni meglio.
L'unica cosa che noto è che nel primo caso, ottengo lo stesso risultato con molta meno fatica :)

Anche se la questione non è di vitale importanza, mi piacerebbe sapere da voi, in linea di massima, quale approccio utilizzate.

Il tutto a prescindere se utilizzate strumenti visuali o fate tutto da codice.

Grazie mille :)

RaouL.

[gugoXX]

Se utilizzi Winform ti consiglio di dare un'occhiata al pattern MVC
Se invece utilizzi WPF ti consiglio di dare un'occhiata a MVVM

Sono simili.
Il concetto principale e' che la GUI deve essere quanto piu' stupida possibile, e deve appoggiarsi lasciando tutta la logica ad un oggetto sottostante, il Controller (O ViewModel per WPF)

Questo ViewModel e' alla fine una istanza di una classe da te scritta.
In questa classe avrai per esempio una stringa, che sara' poi presentata nella label di cui sopra.
Una ListView sara' invece probabilmente una normale List<something>
E l'oggetto selezionato nella ListView sara' un'istanza di questa classe something.
Il codice lanciato dalla pressione di un bottone sara' un metodo di questa classe (vedi Command pattern per cose piu' complicate ma standard)
Anche la pressione del tasto sinistro in punti specifici sara' un metodo di questa classe.
In questo modo si possono scrivere tutti i test logici dell'applicazione e non e' necessario sincronizzare con alcun delegate.
E si fara' istanziando la sola classe logica durante la fase di test, da pilotarsi con i metodi e le proprieta' esposti (Che sono poi quelli utilizzati da e verso la GUI)

Uno dei vantaggi dell'approccio e' quello che si puo' staccare la classe logica dalla GUI, ed utilizzare un'altra GUI compatibile senza dover riscrivere l'applicazione, ma solo la parte di disegno.

Restano fuori 2 parti principali da testare,
- I bindings, che sono i meccanismi secondo cui il controller va a pilotare i pezzi relativi nella GUI (sotto Winform), e che sono invece i meccansimi secondo cui la GUI va a prelevare i dati dal ViewModel (sotto WPF)
- La gui stessa, ovvero gli oggetti prettamente GUI come colori, testo, posizioni.

I bindings vengono trascurati in quanto gli oggetti binding sono gia' dati e scritti e testati in tua vece
La GUI stessa, quando necessario, viene testata con tools appositi che simulano le operaizoni utente e vanno a pescare i dati sulla Form sotto test.
Scrivendo questi test fra l'altro si testano indirettamente anche i bindings.

Ad esempio la libreria White se si lavora sotto Winform e tali test vogliono essere scritti in C#. Sotto WPF ci sono accenni ma non e' ancora maturo.
Se invece si e' contenti di pilotare test di simulazione, lavoro tipico del personale QA, allora ci si affida a tool come Fitness, Selenium, QuickTest Pro e molti altri, dove vengono registrate le azioni del tester (clicco qui, apro la', seleziono qui).
LE operazioni del tester vengono tradotte in script, che possono essere modificati/customizzati, e vengono poi rilanciati in fase di test e ne vengono poi "Asseriti" i risultati che devono essere quelli attesi anche nelle nuove versioni della GUI.